Order cancelled incorrectly but still live on trade Workstation

[Gengger83]

Hello,
i see there was already improvements done on that matter on the last release ( last_release ).
but I run into a behaviour that is similar and seems wrong.
When i am placing a buy Limit Order on a stock, i got this error in the log popping:
"Error 10349, reqId 30: Order TIF was set to DAY based on order preset.
Canceled order: Trade..." I know how to solve this error by adding an argument like tif="GTC" to my limit order but that's not my question.

In the last release, improvement done was on warning, this one is treated as an error so in the wrapper.py there is a cancelledEvent emitted to the trade ( wrapper_link ).
But on Trade Workstation the order is not cancelled and remain active, which leads to an inconsistent state between what i see in my algo and the reality. I can reproduce it this every time I get this error so it is not a one time thing.

Do you face this issue before, do you have some advise ?

Thanks

[mattsta]

Thanks for the note!

So it looks like you are saying maybe also "error code 10349" should be one of those "error is actually a warning, and the trade is still active" conditions we should add here: https://github.com/ib-api-reloaded/ib_async/blob/main/ib_async/wrapper.py#L1512-L1530

We had to make an "exceptions" list to error conditions because IBKR has many cases like you found where the API reports an "error" with an order and says something failed, but the order remains live and just had different default values used instead.

[Gengger83]

yes i tried and indeed by adding it in the list of exceptions it solve the problem.

this can lead to potential dangerous situation if in your algo, because you think the order is cancel you make an other one, or don't hedge it for example...Do you have a mechanism in place when you use this lib so that if this behaviour happen, you have an alert or a way in your algo to detect something is wrong ?

[mattsta]

Do you have a mechanism in place when you use this lib so that if this behaviour happen, you have an alert or a way in your algo to detect something is wrong ?

Sadly the "mechanism in place" is adding those exceptions to the "these errors from the API do not cancel the order" protection list.

I had the same thing happen with some of those other manual conditions (which is why they are there) where I had large buys trigger after I thought they were canceled (because the client library deleted the on a "invalid size increment" error), but they remained live and cleared then I had to unexpectedly manage them out again.

I'll make a note to add this new condition to the "don't delete order" exception list and we can have it improved going forward.