The “outboundAccountPosition” event that comes directly after an “executionReport” will have, always, his Timestamp the same as the “executionReport” event ?
If not, there is a way to tell that an “outboundAccountPosition” is directly related to an “executionReport” ?
Little explication:
I use User Data streams to keep my users balance synced and, If a user sells something through my platform I do some “other calculations” after that sell is completed (filled, partially filled or just closed).
That “other calculations” that I do needs to especially happen AFTER all “outboundAccountPosition” events that are related to that particular sell order are received.
My problem is that I can’t know, before I create the sell order, how many “outboundAccountPosition” events will be generated from that order but somehow I need to know when the last “outboundAccountPosition” is sent after I receive the last “executionReport” (which I know it’s the last based on his status, either Filled or Closed).
In a perfect world it’s easy, after the last “executionReport” I just grab the next “outboundAccountPosition” but I’m afraid that, in times when Binance is very loaded, this 2 events will not be sent in this “perfect” way (exec -> outbound -> exec -> outbound etc).
Can’t guarantee event timestamp for “outboundAccountPosition” and “executionReport” will always be the same.
Unfortunately there’s no direct value at the moment to directly identify the relation between these2 events to see if they belong to the same order.
As far as I can see, we’re about 2 years later and there’s still no possibility to link an order to a balance update issued by that order… which seems a little bit unthoughtful by the people who designed this specific stream!
It wouldn’t be so hard to have another key in the returned json which contains the orderId causing the balance update or null if other action caused that update, wouldn’t it?
This problem leads to unnecessary querying the rest API on every order for a balance update to double check if the amount is right, and even then some problems may arise.
What happens if two orders are sent at the same moment? Does Binance differentiate between their timestamp to deliver user data stream updates regarding the order execution and balance updates in that specific order they were sent?
There are so many unknown variables in this user stream websocket and I really feel like they should be addressed in the official documentation on GitHub.
From preliminary testing, it seems that executionReport always comes first and outboundAccountPosition after. With this assumption, one can optimistically update local balances based on trade data from executionReport which will eventually get overridden by outboundAccountPosition.
Curious if anyone has successfully used this approach.