Failed Order Modifications Result in False Order Cancelleations

[mattsta]

Scenario:

Modification of an existing order (e.g. original is: SELL SPX option at 66.00) to a new (accidentally invalid) price (modify to: SELL SPX option at 45.55) causes IBKR to cancel the modification because of bad price increment, which results in:

• IBKR state being -> Submitted, Modified, Cancelled
• but only the modification was canceled, so original order is still open
• when ib_insync sees "Order -> Canceled" it removes the entire pending order from .openTrades() and .openOrders() until a full API reconnect

Example trade/order log state:

log=[
TradeLogEntry(time=_, status='Submitted', message='', errorCode=0),
TradeLogEntry(time=_, status='Submitted', message='Modify', errorCode=0),
TradeLogEntry(time=_, status='Cancelled', message='Error 110, reqId 10781: The price does not conform to the minimum price variation for this contract.', errorCode=110)
]

So the modification was canceled and the order is still open, but the status='Cancelled' event is removing the trade state entirely until a fresh API fetch on startup.

Not sure the best way to handle this unless we can detect something like "Modify log entry followed by Cancelled/Error log entry doesn't remove the order;" or we could just do a full refresh of all server-side orders after any Cancelled event to properly maintain local state matching IBKR state?

[erdewit]

Thank you for the detailed bug report. A simple solution is to treat error 110 as a warning, so that ib_insync will not consider the modified order as canceled. A new order that gets error 110 will still be properly canceled via the orderStatus wrapper method.

[mattsta]

Nice place to fix it. Thanks! If I find more invalid cancel conditions I'll test them using the warningCodes set then submit more updates.

[Henry-E]

Found a possible bug linked to this change. Where a 110 error no longer registers as a cancelled order when submitting a new order.

More details here https://groups.io/g/insync/message/9259