开云体育

This is not manual. Of course, pre-submitted and submitted statuses are also coming when relevant.
What happened is a failed price modification attempt. PlaceOrder is sent with a new price and the same id for modification, it happens to be just executed, hence the rejection. But there should not be a cancellation as the original orderId is executed, but the 'new' duplicate one is rejected. This is my understanding it should be submitted first before it can be cancelled. And if we assume the order was somehow considered 'new' by IB there should be a duplicate id error instead.

You mean error 103 ?
I recommend that you have to live with the reported 'error' "Cancelled",? The reported error-ed situation from IB seems sound and usable.

Interesting case!
What you try to do is requiring a very complex analysis to decide that it is a 103 and at pretty fast pace considering all the thing that happens during resolution of the execution.

I am not surprised and I won't expect better. Here you dealt within less than 150 ms to: transmit/receive, reroute, choose BBO with a reservation process, execute and clear the order, with delay including exchange servers, while in the middle of that you call for a reprocessing of the same order.
Way faster is feasible but it's way more expensive.

Programmatically sound and easy (and this is even IB recommendation) would be that you cancel your order then do a new one with new pricing.
Consider that, it that may fit your need. And look at the flexibility IB offer to modify an existing as a way to improve performance (Update is cheaper than Delete+Insert), but with the risk that it create complex situation for IB like what you do which is a modification sent while execution is probably in the clearing phase.
Hence an error message as a rejection that I can understand as reflecting exactly what IB experienced, and not a clear cut 103.
BTW can even be more perilous with some order kind that require slack, look at error 440 or 129 (never tried an order that may generate it)