I am using kite.orders() to print open and trigger pending orders, its showing open orders ( open cover orders which are not triggered yet) as trigger pending..
When you place a cover order with an entry type limit the first leg will be OPEN status and the second leg will be TRIGGER PENDING until the trigger is hit.
Continuation to the above query : If I cancel an executed CO order with status = "trigger pending" , I get two postback requests with status = "CANCELLED".
The only difference in the two requests is with the "pending_quantity" field, whose sequence is unpredictable. (Sometimes I get request with pending order first and later get the one without pending order later and vice versa).
One has suggested to implement two websocket connections, as this issue happens with load on the threading to process tick data; of the two websocket connections, one is to handle the data_fetch and order placement, other to monitor postback requests and misc activities. Is this a good practice?
Query 2: Say, if in my CO order(quantity = 100), 45 quantity gets executed and 55 is pending.
If trigger is executed/ cancelled, may I have a picture of what will the postback fields on quantities look like.(quantity, filled_quantity, pending quantity, cancelled_quantity).
One has suggested to implement two websocket connections, as this issue happens with load on the threading to process tick data; of the two websocket connections, one is to handle the data_fetch and order placement, other to monitor postback requests and misc activities. Is this a good practice?
Mis-match in order update sequence can be either because of the async nature of order update broadcast or your local tick processing block. You can try implementing two Websocket and test the same or maybe you can add a little buffer period, before performing any computation based on these async order updates. This thread gives more insight.
if in my CO order(quantity = 100), 45 quantity gets executed and 55 is pending. If trigger is executed/ cancelled, may I have a picture of what will the postback fields on quantities look like.(quantity, filled_quantity, pending quantity, cancelled_quantity).
An UPDATE postback is triggered when an open order is modified or when there's a partial fill. So, you will receive two order update status, one UPDATE for partial fill and the second for left cancel/completed.
Continuation to the above query :
If I cancel an executed CO order with status = "trigger pending" , I get two postback requests with status = "CANCELLED".
The only difference in the two requests is with the "pending_quantity" field, whose sequence is unpredictable. (Sometimes I get request with pending order first and later get the one without pending order later and vice versa).
One has suggested to implement two websocket connections, as this issue happens with load on the threading to process tick data; of the two websocket connections, one is to handle the data_fetch and order placement, other to monitor postback requests and misc activities. Is this a good practice?
I am open to all suggestions.
Thanks in advance.
Say, if in my CO order(quantity = 100), 45 quantity gets executed and 55 is pending.
If trigger is executed/ cancelled, may I have a picture of what will the postback fields on quantities look like.(quantity, filled_quantity, pending quantity, cancelled_quantity).