Orders not cancelling

[lkaino]

I have changed nothing in my code, suddenly today the cancelOrder stopped working and I lost some money. My client failed to cancel two different orders:

Here's the log from the Trade for one of them:

My client issued the first cancel a second after submitting the order. Then issued a second cancel 6 seconds after that. The order went to PreSubmitted state 8 seconds after the second cancel and filled after that.
log=[13:49:43, PendingSubmit; 13:49:44, PendingCancel; 13:49:50, PendingCancel; 13:49:58, PreSubmitted; 13:49:58, PreSubmitted, Fill 19.0@2.47; 13:49:58, Filled]

Has anyone else noticed this? Nothing should have changed on my side, and the cancelling was working fine yesterday.

[mattsta]

Yeah, sometimes orders get filled before updates can be processed due to how IBKR systems and the market works.

The primary problem is orders can fill in milliseconds (or faster) while our requests to update IBKR with new settings (price/size modifications, cancel requests) can take anywhere from 1 to 10 seconds.

If we have a live order, then we submit a cancel at time N, but IBKR takes 3 seconds to move our cancel request to the market, the request can still fill at any time between N and N+3 seconds. The market never saw the cancel request and it's out of our hands.

I've even seen some orders go directly from PreSubmitted -> Filled with nothing else in the middle during busy times, but at other volatile times, I've seen order placement or modification take 10 seconds to move from PreSubmitted (reaching IBKR) to Submitted (reaching an exchange) — in the "between time" from submitting a new request and the request reaching the market, the old size/price/orders are still in full effect and there's nothing we can do about it (and IBKR doesn't have any guarantee for API to market update latency; it can take milliseconds or 10+ seconds for API requests to reach the market).

The only safe solutions I've found:

• scale in smaller over time so any unexpected price movements don't cause significant damage to a large unprofitable position
• use automatic OTOCO attached orders for a stop loss order (stop limit or trailing stop limit works there too) and/or take profit, so when an initial order fills, the sub-orders are already at IBKR to begin executing live if price moves rapidly in too bad or too good directions (without needing another unpredictable API->market request cycle)
• if you just want a price change, make sure to submit an order modification (same order, new limit price or quantity change) instead of full cancel + new order cycle.

[lkaino]

Thanks for the detailed answer! That makes sense and I do expect some delay in the order executions.

But in this case it took almost a minute from the cancel command to the buy order filling:

13:42:40, PendingSubmit;
13:42:41, PendingCancel;
13:42:43, PendingCancel;
13:43:35, PreSubmitted;
13:43:35, PreSubmitted, Fill 6.0@8.185;
13:43:35, Filled

Hopefully it was an issue only today. I restarted my IB gateway, hopefully it won't happen again tomorrow. I haven't scaled up my position size yet, but it would be awful if this happened with bigger positions.

I also removed the double cancelling from my code, maybe that affects it somehow.

[mattsta]

One minute does seem like a very long time for a change to be queued up on their side. I guess just double check all your order logic for unexpected edge cases too.

It's also possible there was a delay in the fill notification and your trade actually filled near or before your cancel request, so the cancel was ignored because it already matched live. The timestamps in the event log are your local system time when the IBKR client sees the event update, but not the execution time. You would have to check the list of executions to see the actual exchange execution time of the trade.

My cancel logs show a standard cancel reporting flow happens as PendingSubmit -> PreSubmitted -> Submitted -> PendingCancel -> Cancelled. All those status levels come from the IBKR API side, so those steps are just updated by the client library but not controlled by the client library.

It also helps to keep a full log of the client output for later reference just so you can verify the order of what actually happened historically. You can create a simple log file automatically like this or attach event handlers to order status updates for custom reporting:

        logging.basicConfig(
            level=logging.INFO,
            filename=f"mylog-{time.time()}-ibkr.log",
            format="%(asctime)s %(message)s",
        )