@sujith Some of the order IDs for which we didn't receive Postback (For your reference): 200626200399385 200626200399376 Some of the order IDs for which we have received Postback (For your reference): 200626200428393 200626200909108
@Vivek and @sujith I don't even know how to react to this. Postback failures cost us a lot of orders and money. At least an apology was in order I guess. This time at least we have a consensus that indeed some postbacks weren't sent at your (Zerodha's) end. Please please please rectify this in the future and I really hope you do. God forbid if it happens again, please be proactive and send out an alert saying Postbacks are dropped for this duration.
@sujith@Vivek as pointed in @ArthaKalpa screenshot here - the ArthKalpa's(AK) client is sending 200 or success response back to ZerodhaServer for each successful postback that they are receiving. Can Zerodha use this response back from clients like AK and use some timeout feature to see which responses are not successfully responded by the client to send back the postbacks that were not sent or missed out? Please, consider this as a feature request. Happy to share ideas or discuss further with the Zerodha team as it helps a larger Zerodha community.
@SandeepKV, It is just a notification service. It will send you ping with data when available. It doesn't have any context or storage or any kind of queue mechanism. I am afraid, we can't make any changes for this as of now.
If your use case doesn't suit postbacks then I would suggest using the websockets API order updates to listen to the order events.
@sujith and @Vivek Sorry. I don't understand this ambiguity. There were a few postbacks that were lost on 26th June 2020. Right @Vivek ? I thought Vivek is with Zerodha and he agreed to this. Am I wrong?
Sorry. I don't understand this ambiguity. There were a few postbacks that were lost on 26th June 2020. Right @Vivek?
Yeah, we accept the issue of 26th June. That was just an exception on 26th June ( issue limited to period 10 AM-11 AM). You can't generalize(happening all the time) the exception. Last time, as stated here, we tried reproducing the same multiple times at our end. But, all responses were fine. Alternatively, if you are frequently facing issues regarding postback status, might have an alternate system at your end for the same. Might periodically fetch order history with required order_id collected during order placement and look for order_status(OPEN, COMPLETE, CANCELLED, etc).
@Vivek@rakeshr@sujith Please note that I have never generalized (happening all the time) the exception. In fact, the topic name itself has "Intermittent" in it. My response was in clarification to Sujith's concern about why only we are facing issues. Good that we are all on the same page. As Rakesh suggests, we will implement that periodic GET orders at our end to make it more robust.
@sujith Just to get a better picture, how did others deal with missing postbacks on 26th of June? Why haven't anyone posted a discussion regarding this, except for us? We find it kinda difficult to comprehend the situation...
I being one of those others, would want to say that
some of us don`t use Postbacks but websocket.
and there are many pain points on daily basis regarding trading, but one has just learnt to live with it.
as there are no solution to them. if they happen they are very slow any way. ( when they are to do with NSE or SEBI or Min of Finance. ) . Otherwise what is right about the regulations of exchange and SEBI? they are all painful and colonial.
when it comes to Zerodha. one understands that these are technical glitches while in covid-19 era. not many people doubt their intentions. at least i don`t.
Althou i too tend to loose because of such glitches. It is a sad affair but what can be done?.
@trade_then Thanks for joining the discussion Did you move to websocket coz Postbacks was more painful (glitchy) or did you start off with websocket itself? - We are planning to stick with Postbacks as we might have to cater to multiple accounts (though it's a dream right now). We definitely don't doubt Zerodha's intentions. Regarding SEBI, we are all in this together I guess... All we can do is make our systems more robust. I am pretty sure even Zerodha is also striving to make its system more and more robust each passing day.
Well i started with websocket itself. Therefore i am saved of Postback problem.
My major sour point is
waiting for order to complete. that really bugs me when i have placed an order and it awaits approval, and by the time price position ( trade advantage ) has reversed.
at that time one does not know where to jump, out of window or up the roof.
Regarding dealing with multiple clients. i have following suggestion. thou i am no expert so please forgive me if i appear foolish suggesting.
In my app which is personal to me.
many charts and strategies have to work together and each requires same data. They are all independent apps by themselves each doing some kind of churning.
So inside my app i receive order status and ticks via Websocket which is further distributed to all other processes ( in my case processes being clients ) via
Some of the order IDs for which we didn't receive Postback (For your reference):
200626200399385
200626200399376
Some of the order IDs for which we have received Postback (For your reference):
200626200428393
200626200909108
Thanks
I don't even know how to react to this. Postback failures cost us a lot of orders and money. At least an apology was in order I guess. This time at least we have a consensus that indeed some postbacks weren't sent at your (Zerodha's) end. Please please please rectify this in the future and I really hope you do.
God forbid if it happens again, please be proactive and send out an alert saying Postbacks are dropped for this duration.
It is just a notification service. It will send you ping with data when available. It doesn't have any context or storage or any kind of queue mechanism. I am afraid, we can't make any changes for this as of now.
If your use case doesn't suit postbacks then I would suggest using the websockets API order updates to listen to the order events.
Is websocket API more reliable compared to postback?
If postbacks have failed, how does Zerodha's UI get the executed order information?
Use what as an event to fetch orderbook?
Again, so WebSocket is more reliable than postbacks?
Sorry. I don't understand this ambiguity. There were a few postbacks that were lost on 26th June 2020. Right @Vivek ?
I thought Vivek is with Zerodha and he agreed to this. Am I wrong?
Like @Vivek has mentioned, this was an unexpected incident. It doesn't happen often.
Last time, as stated here, we tried reproducing the same multiple times at our end. But, all responses were fine.
Alternatively, if you are frequently facing issues regarding postback status, might have an alternate system at your end for the same. Might periodically fetch order history with required order_id collected during order placement and look for order_status(OPEN, COMPLETE, CANCELLED, etc).
Please note that I have never generalized (happening all the time) the exception. In fact, the topic name itself has "Intermittent" in it. My response was in clarification to Sujith's concern about why only we are facing issues. Good that we are all on the same page.
As Rakesh suggests, we will implement that periodic GET orders at our end to make it more robust.
Thanks guys
Just to get a better picture, how did others deal with missing postbacks on 26th of June? Why haven't anyone posted a discussion regarding this, except for us? We find it kinda difficult to comprehend the situation...
- some of us don`t use Postbacks but websocket.
- and there are many pain points on daily basis regarding trading, but one has just learnt to live with it.
as there are no solution to them. if they happen they are very slow any way. ( when they are to do with NSE or SEBI or Min of Finance. ) .Otherwise what is right about the regulations of exchange and SEBI? they are all painful and colonial.
when it comes to Zerodha. one understands that these are technical glitches while in covid-19 era.
not many people doubt their intentions. at least i don`t.
Althou i too tend to loose because of such glitches. It is a sad affair but what can be done?.
Thanks
Regards
Thanks for joining the discussion
Did you move to websocket coz Postbacks was more painful (glitchy) or did you start off with websocket itself? - We are planning to stick with Postbacks as we might have to cater to multiple accounts (though it's a dream right now).
We definitely don't doubt Zerodha's intentions.
Regarding SEBI, we are all in this together I guess...
All we can do is make our systems more robust. I am pretty sure even Zerodha is also striving to make its system more and more robust each passing day.
Please throw some light over this concern of ours...
Therefore i am saved of Postback problem.
My major sour point is
- waiting for order to complete. that really bugs me when i have placed an order and it awaits approval, and by the time price position ( trade advantage ) has reversed.
- at that time one does not know where to jump, out of window or up the roof.
Regarding dealing with multiple clients. i have following suggestion.thou i am no expert so please forgive me if i appear foolish suggesting.
In my app which is personal to me.
- many charts and strategies have to work together and each requires same data. They are all independent apps by themselves each doing some kind of churning.
So inside my app i receive order status and ticks via Websocket which is further distributed to all other processes ( in my case processes being clients ) via- NamedPipes or
- Memory Mapped Files..
Similarly you can receive all updates at a central location. from where you push it further to yourclients via
- TCP
- or
- Websocket Itself
Because Http has lot of latency attached to it.I think a branch of Kiteconnect should evolve to using websocket or TCP to increase the throughput.
and robustness of system.
Admittedly i never dealt with Web or clients so whatever i have said might be rubbish in that context.
my apologies for that.
Thanks
Regards