I have 2 test cases, reproduced below In this case seems kite is having some problem with round number.
case 1: calling the function kiteGTTBuy("VTL", "NSE", 1207.00, 1, 1225.05); throws error: Fatal error: Uncaught InputException (400) 'Invalid condition params.' thrown in kiteconnect.php on line 1131
while case 2 same function works. kiteGTTBuy("VTL", "NSE", 1207.05, 1, 1225.05);
only difference is with the price 1207.00 (case1) vs 1207.05 (case2)
Here is the function below. function kiteGTTBuy($symbol, $exchange, $price, $qty, $last_price) { $kite = new KiteConnect(ZERODHA_API_KEY); $kite->setAccessToken(ACCESS_TOKEN);
$params = [ // GTT type, its either `$this->kite::GTT_TYPE_OCO` or `$this->kite::GTT_TYPE_SINGLE`. "trigger_type" => $kite::GTT_TYPE_SINGLE, // Tradingsymbol of the instrument (ex. RELIANCE, INFY). "tradingsymbol" => $symbol, // Exchange in which instrument is listed (NSE, BSE, NFO, BFO, CDS, MCX). "exchange" => $exchange, // List of trigger values, number of items depends on trigger type. "trigger_values" => array($price), // Price at which trigger is created. This is usually the last price of the instrument. "last_price" => $last_price, // List of orders. Check [order params](https://kite.trade/docs/connect/v3/orders/#regular-order-parameters) for all available params. "orders" => array([ "transaction_type" => $kite::TRANSACTION_TYPE_BUY, "quantity" => $qty, "product" => $kite::PRODUCT_CNC, "order_type" => $kite::ORDER_TYPE_LIMIT, "price" => $price ]) ]; print_r($params); print_r($kite->placeGTT($params)); }
This won't fix the above issue. As the issue is while generating URL-encoded query string for POST request. This part of the code.
In this case seems kite is having some problem with round number.
Yes, this is a known issue and we have already taken care of this in our new refactor version using the Guzzle HTTP client form_params option. We are almost done with the review to publish our new refactored PHP client on Composer. Once live on the composer, we will announce the same on the forum.
Thanks for pointing out the problem area. Seems changing the regex in $payload = preg_replace("/%5B(\d+?)%5D/", "", $payload); with $payload = preg_replace("/%5B([\d+])?([\.\d])%5D/", "", $payload);; seems to fix my particular issue.
Hope it doesn't break anything else. Have tested it for last few days, seems good so far. But needs to be tested well.
Can some one from Zerodha please respond to this.
My code currently looks like this, which is not very pleasing.
$tillZerodhaFolksWontFixThisGTTBug = ($thisPrice == round($thisPrice));
if ($tillZerodhaFolksWontFixThisGTTBug) {
...
} else {
...
}
We are almost done with the review to publish our new refactored PHP client on Composer. Once live on the composer, we will announce the same on the forum.
This won't fix the above issue.
.Yes, it's just a work around by increasing or decreasing the price by 5 paise to avoid the issue.
Seems changing the regex in
$payload = preg_replace("/%5B(\d+?)%5D/", "", $payload);
with
$payload = preg_replace("/%5B([\d+])?([\.\d])%5D/", "", $payload);;
seems to fix my particular issue.
Hope it doesn't break anything else. Have tested it for last few days, seems good so far.
But needs to be tested well.