Cancellation of inactive orders

[rgeronimi]

The code managing the cancellation of inactive orders (

ib_insync/ib_insync/ib.py

Line 681 in 006fcfc

or status == OrderStatus.Inactive):

)
declares them immediately as Cancelled, as opposed to PendingCancel. There is one common case where this seems premature: unavailable shares to short. In these case, IB declares the order as inactive, but it is still looking for these shares and could at any moment execute the order should new borrowable shares become available (I practice short-selling quite a lot and this is often unpredictable).
To handle these cases properly inactive orders shall be removed from this condition, i.e. declared as PendingCancel until the server confirms the effective cancellation.

Note: I have only a cursory understanding of how the library and the IB API interact so I may be completely wrong. For example I don't know if the server does send a cancellation confirmation for inactive orders.

[erdewit]

When canceling an Inactive order, IBKR sometimes does not send a status update back. This leaves the order hanging in the PendingCancel state forever. To prevent that, Inactive orders are set to Cancelled right away when canceled. You are right that there's still a time window (in the order of 100 ms) where it could be filled.

[rgeronimi]

I have had cases like that, with high-volume high-frequency low-quantity orders.

One solution could be to launch an asynchronous task which sleeps 3 seconds, checks the state and if it is not cancelled switches it to cancelled and emits the appropriate events. That would definitely kill my cases which were very tight in terms of timing, as you mentionned.

That would require a careful review of the lib code to be sure that we do not create race conditions with the rest of the code that depends on this status. However as the library is cleanly modularized and fully async( same thread which simplifies race condition analysis - we only look for await statements) this analysis seems doable:

I just had a look into the wrapper code, it does not use a single await or has any async method. Consequently this asynchronous task would never interfere with ongoing wrapper method execution (it would be executed either before or after any wrapper method, but never in parallel). But maybe I am missing a bigger risk outside of the wrapper class.

[erdewit]

One solution could be to launch an asynchronous task which sleeps 3 seconds, checks the state and if it is not cancelled switches it to cancelled and emits the appropriate events

I think that's a good idea.

[goodboy]

I actually just ran into this as well particularly when firing lots of orders and then quickly cancelling right away in a batch.

I might put up a patch for this and test in our production stuff 🏄🏼