Redundant postback (repost)

joy

Hi,
First congrats on the API and glad to see the postback via the websocket

Now I am facing this scenario. While modifying an order I am receiving 2 postbacks. The first one updates me the new price/quantity etc the second postback sends the previous price/quantity etc data which is totally redundant. The following further illustrates it.

PUT request submitted to change order price to 258.9

03Jul18 09:48:30, PUT|apiKey=apiKey, accessToken= accessToken, Url=https://api.kite.trade/orders/regular/180703000353787, Payload= exchange=NSE&tradingsymbol=HINDPETRO&transaction_type=SELL&order_type=LIMIT&product=CNC&quantity=100&price=258.9&validity=DAY

Post back received - this is fine

03Jul18 09:48:30, WebSocket_MessageReceived : {"type":"order","data":{"placed_by":"clientId","order_id":"180703000353787","exchange_order_id":"1100000001068459","parent_order_id":null,"status":"OPEN","status_message":null,"order_timestamp":"2018-07-03 09:48:32","exchange_update_timestamp":null,"exchange_timestamp":"2018-07-03 09:48:32","variety":"regular","exchange":"NSE","tradingsymbol":"HINDPETRO","instrument_token":359937,"order_type":"LIMIT","transaction_type":"SELL","validity":"DAY","product":"CNC","quantity":100,"disclosed_quantity":0,"price":258.9,"trigger_price":0,"average_price":0,"filled_quantity":0,"pending_quantity":100,"cancelled_quantity":0,"market_protection":0,"meta":null,"tag":"c8db7faa","guid":"WnZBklGc2xzZxDKa","account_id":"clientId","unfilled_quantity":0,"app_id":106,"checksum":""}}

A second postback received, however it contains the old price - this is redundant.

03Jul18 09:48:30, WebSocket_MessageReceived : {"type":"order","data":{"placed_by":"clientId","order_id":"180703000353787","exchange_order_id":"1100000001068459","parent_order_id":null,"status":"UPDATE","status_message":null,"order_timestamp":"2018-07-03 09:48:32","exchange_update_timestamp":null,"exchange_timestamp":"2018-07-03 09:48:32","variety":"regular","exchange":"NSE","tradingsymbol":"HINDPETRO","instrument_token":359937,"order_type":"LIMIT","transaction_type":"SELL","validity":"DAY","product":"CNC","quantity":100,"disclosed_quantity":0,"price":259.65,"trigger_price":0,"average_price":0,"filled_quantity":0,"pending_quantity":100,"cancelled_quantity":0,"market_protection":0,"meta":null,"tag":"c8db7faa","guid":"WnZBklGc2xzZxDKa","account_id":"clientId","unfilled_quantity":0,"app_id":106,"checksum":""}}

Response received - this is fine

03Jul18 09:48:30, OrderId : {"status":"success","data":{"order_id":"180703000353787"}}

Query is why you are sending the stale postback. Isnt it redundant? How to filter the same? Can I assign a TAG while modifying/cancelling an order.


P.S. - I posted earlier today, however I edited it and it went to moderation and seems got lost.

sujith

If you look at the order history of this order you can see that there are several order status change like MODIFY VALIDATION PENDING, MODIFY PENDING, MODIFIED, OPEN.
OMS sends these values. I think OMS doesn't update the value unless the modification is successful.
The order of postbacks is first you will receive postback with UPDATE status and then OPEN after modification is successful.
We will speak to OMS team to check if we can do something about this but for now, an intermediate solution is to ignore postback with UPDATE status and older value.

joy

@sujith thanks for the clarification.

The order of postbacks is first you will receive postback with UPDATE status and then OPEN after modification is successful.

We are receiving the OPEN postback first and then the UPDATE. this conflicting race condition is an issue.

Cant ignore the UPDATE postbacks as it will blind us in case of partial fills etc. Things gets even murkier in case we modify a partially filled order. Let me exemplify.

Modified a partial filled order to 259.65

03Jul18 10:30:37, PUT|apiKey=apKey, accessToken= accessToken, Url=https://api.kite.trade/orders/regular/180703000617209, Payload= exchange=NSE&tradingsymbol=HINDPETRO&transaction_type=SELL&order_type=LIMIT&product=CNC&quantity=100&price=259.65&validity=DAY

Post back received for the same. Here the status is UPDATE not OPEN

03Jul18 10:30:37, WebSocket_MessageReceived : {"type":"order","data":{"placed_by":"clientId","order_id":"180703000617209","exchange_order_id":"1100000001801439","parent_order_id":null,"status":"UPDATE","status_message":null,"order_timestamp":"2018-07-03 10:30:40","exchange_update_timestamp":null,"exchange_timestamp":"2018-07-03 10:30:40","variety":"regular","exchange":"NSE","tradingsymbol":"HINDPETRO","instrument_token":359937,"order_type":"LIMIT","transaction_type":"SELL","validity":"DAY","product":"CNC","quantity":100,"disclosed_quantity":0,"price":259.65,"trigger_price":0,"average_price":259.4,"filled_quantity":37,"pending_quantity":63,"cancelled_quantity":0,"market_protection":0,"meta":null,"tag":"f3f2b13d","guid":"qvYFlXD1peviuRW1","account_id":"clientId","unfilled_quantity":0,"app_id":106,"checksum":""}}

Received the stale postback with the status as UPDATE and the pre-modified price. This should have come first. Please check this at your end.

03Jul18 10:30:37, WebSocket_MessageReceived : {"type":"order","data":{"placed_by":"clientId","order_id":"180703000617209","exchange_order_id":"1100000001801439","parent_order_id":null,"status":"UPDATE","status_message":null,"order_timestamp":"2018-07-03 10:30:40","exchange_update_timestamp":null,"exchange_timestamp":"2018-07-03 10:30:40","variety":"regular","exchange":"NSE","tradingsymbol":"HINDPETRO","instrument_token":359937,"order_type":"LIMIT","transaction_type":"SELL","validity":"DAY","product":"CNC","quantity":100,"disclosed_quantity":0,"price":259.4,"trigger_price":0,"average_price":259.4,"filled_quantity":37,"pending_quantity":63,"cancelled_quantity":0,"market_protection":0,"meta":null,"tag":"f3f2b13d","guid":"qvYFlXD1peviuRW1","account_id":"clientId","unfilled_quantity":0,"app_id":106,"checksum":""}}

Received the response - this is fine

03Jul18 10:30:37, OrderId : {"status":"success","data":{"order_id":"180703000617209"}}

Given the OMS is designed as such dont think TR/Omnesys is going to change it. Potential workarounds:

• Give the actual postback status instead of UPDATE
  
• Maintain the chronology and send the messages as they come. (even then can we rule out a race condition?)
  
• A TAG property while modifying/cancelling order.
  

sujith

Cant ignore the UPDATE postbacks as it will blind us in case of partial fills

This is exactly why we can't stop sending UPDATE status postbacks.

The issue wherein order of postbacks is wrong is something happening because of OMS. We just relay postbacks as and when we receive the signal from OMS.

There are many intermediate statuses, sending the exact status may panic some other user's system as some people work on a specified set of statuses.

Order tags already exist, a user can tag an order while placing it.

joy

This is exactly why we can't stop sending UPDATE status postbacks.

Just send it once (when the order state is open) or keep the chronology correct, if possible.

The issue wherein order of postbacks is wrong is something happening because of OMS. We just relay postbacks as and when we receive the signal from OMS.

ya, tell them to fix it.

There are many intermediate statuses, sending the exact status may panic some other user's system as some people work on a specified set of statuses.

ok, I read it as a limitation at your end

Order tags already exist, a user can tag an order while placing it.

thats for entry orders only. I am requesting the same for order modification/cancellation too.


Overall the postback notification implementation is pretty impressive given it works across multiple platforms seamlessly and kudos to you for that. However much of the shine is lost due to the fact you have made the "state" exotic, redundant postbacks and random chronology.

joy

Another update, the API is returning the status as OPEN when filled_quantity == 0. However in case of partial fill the status is retuned as UPDATE always. Is this by design or a bug. Nest Trader shows the status as OPEN in both the scenario (please see the attached screenshot.

jjiteshh

Hey guys,

I was trying to work on the postback messages using the webhook method before I landed on this page..

Are you guys saying I can get messages for my order status using websocket? If so, where can I find more information on this. I have been searching for this in the Kite Documentations.

Thanks

jjiteshh

I am asking because Joy at the start of thread said so...


from Joy---

Hi,
First congrats on the API and glad to see the postback via the websocket

sujith

@jjiteshh,
You can find the documentation about it here.

jjiteshh

@sujith

Hey thanks for the response.

I am using the KiteConnect Library for Python.

Am I supposed to use the following callback to get postback messages? If so, is there any documentation or an example of how i can use it?

on_order_update(ws, data) - Triggered when there is an order update for the connected user.

Thank You!

jjiteshh

Okay the callback worked as expected...

Thanks