开云体育

on the Cancelled: filled and remaining are 0 , so I won't be bothered, everything reported is consistent.

you should be ready to handle a couple of extraneous orderStatus (or none) as per doc:

There are a couple of thing IB is in charge to do while processing your order, it may happens a few did triggered but became irrelevant, read

I can speculate at 09:32 that there are a lot of action on QQQ,
so that there are more than one opportunity (venue) where to execute your order,? and once one was achieved other one are internally cancelled but some remnant of aborted action are reported (consistently)

not sure you will ever get an answer to your question.
Recommendation: keep aggregating info from orderStatus based on orderid (or if lost fall back on permid).
and If you want to know more then call the 'referee' execDetails to know precisely what was done and how.

You give us very little to work with. For example, was this order in an OCA group with other orders, or did it have an Order Condition that could have caused a cancellation, ...

Gordon pointed you to the right places for some background. The first sentence of "Considerations for Automated Systems" is probably one of the most important considerations where its says "... it is important to monitor for callback notifications, specifically for

When we get a "Cancelled" order status (for example from a "self destruct" price condition on limit orders, an OCA group, or order cancellation request) we always get an error 202 callback (more an informational message than an error). errorMsg in that callback usually contains the reason for the cancellation.

Any chance you have logged that, too?

闯ü谤驳别苍

From my perspective what you describe look strange.
It is unclear to me if you experience this while using TWS manually or trough a section of code. I assume trough coding then I would look at your code logic first.

1- you can expect to receive a ::openOrder call back as the first call back once you have submitted your order.

"Immediately after the order was submitted correctly, the TWS will start sending events concerning the order's activity via and "

With status "PreSubmitted" maybe but it should be called.
This look like an acknowledgment of an (but nowhere does IB doc write this explicitly, look like an implicit)
Practically I also always get at least one? ::orderstatus call back just after the::openOrder call back and before any execDetails

2- The execDetails call back happens later(at least for me).
As the name imply it, it is sent only once the order had been fulfilled at least in part.

3- The error message you report give the impression that you re-submit an order using the already used orderid 97536 and expired (bcs executed)
Luckily for you as the order had been filled, you cannot re-use same orderid, as re-using it ought to be interpreted as request to change something in the order, but as it was already filled up, nothing now can be changed, then the extra order is rejected.

Assuming the datetime reported does reveal the sequence of events, the 'Cancelled' status did apply to the re-submitted order.
try to log on your own any call to placeOrder, including the orderid you used

And yes, I always get openOrder with Filled status after execDetails, even if with a few ms delay.

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)