Keyboard Shortcuts
Likes
Search
Stale quantity in open order event
I had the following sequence:
1. Submit order 2. Receive partial fill 45 ms later. 3. Change quantity 60 ms later 4. Receive three open order events with new quantity. ==>5. Receive three open order events with OLD quantity.<== 6. Receive fill for remaining quantity at new quantity. 7. Receive order status of filled for new quantity 519 ms later This is obviously a bug.? I have never seen it before.? Does anyone have a solution they are confident is correct?? I could ignore the open orders with the old quantity, but whats to say they wrong and the new right?? Sometimes I manually change quantities, so ignoring the stale quantity open order events is not a great solution. |
Nick
¿ªÔÆÌåÓýIt may not work for you but I ignore order status. After all, IB's inner workings are not my concern. All I care about is executions which I can get from exec or position messages.On 12/24/2015 5:20 PM,
fbell50@... [TWSAPI] wrote:
? |
Or add logic to detect and ignore outdated orderStatus/openOrder messages. *As far as I know*, those messages which appear to be the latest (based on content like status or 'filled' quantity) can be relied upon. That is, status or 'filled' does't actually go backwards, and such messages can be ignored without causing further problems. (Apparently servers do things in parallel and responses aren't always in sequence.)
|
How do you identify outdated order status/open order events?? Since orders can be changed manually, just ignoring events that do not match my records is not sufficient. From: "tron001@... [TWSAPI]" To: TWSAPI@... Sent: Saturday, December 26, 2015 7:50 PM Subject: [TWS API] Re: Stale quantity in open order event
?
Or add logic to detect and ignore outdated orderStatus/openOrder messages. *As far as I know*, those messages which appear to be the latest (based on content like status or 'filled' quantity) can be relied upon. That is, status or 'filled' does't actually go backwards, and such messages can be ignored without causing further problems. (Apparently servers do things in parallel and responses aren't always in sequence.)
|
Frank, if you need to deal with unexpected arbitrary manual changes, your situation may be more complicated. However your example mentioned times of 45ms and 60ms, which are not really likely to be manual changes, unless you are really fast at typing. ;-)
In terms of your example, I was expecting "you" to know the "new" quantity, which would of course allow you? sort out any openOrder and orderStatus messages which might refer to a different quantity. By the way, was the message in step 6 an orderStatus message with fillled+remaining = old quantity, or was remaining already zero, yet the status not given as 'filled"? That would be strange. |
The last bad openOrder/status (450 ms since quan change request) is immediately followed by a good one with a filled status.? While manual changes are very rare, I do not want to start guessing which openOrder/status events should be ignored.? I have opened a ticket with IB. From: "tron001@... [TWSAPI]" To: TWSAPI@... Sent: Saturday, December 26, 2015 11:22 PM Subject: [TWS API] Re: Stale quantity in open order event
?
Frank, if you need to deal with unexpected arbitrary manual changes, your situation may be more complicated. However your example mentioned times of 45ms and 60ms, which are not really likely to be manual changes, unless you are really fast at typing. ;-) In terms of your example, I was expecting "you" to know the "new" quantity, which would of course allow you? sort out any openOrder and orderStatus messages which might refer to a different quantity. By the way, was the message in step 6 an orderStatus message with fillled+remaining = old quantity, or was remaining already zero, yet the status not given as 'filled"? That would be strange. |
Well, although there may be something specific to this situation that can be improved, I expect that with asynchronous communication buffered in both directions (which is usually more performant than a synchronized API) and possibly multiple servers, to some degree you may always receive status messages that were already en route before you changed the order, for example.
|