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

开云体育

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?

闯ü谤驳别苍

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.

No I don't want IB to send it to the exchanges. Otherwise, others may see it, putting me at a disadvantage.

Look at tag 6010.
But I doubt they are sent to Exchanges, (Why do you need exchange to hold it ? )
1- Since you use IBKR FIX in many situations you might be routed last second to any exchange.
2- They are part of Custom Tag,

But I guess that it will fulfill your need unless you want to FIX directly to exchange. (then it become a case by case issue)

Does anyone know if orderRef is sent to the exchanges? If so, which FIX tag?

That makes a lot of sense. Thank you.

I don't know of any definitive documentation, but my best guess is that the Execution Condition gets triggered as soon as IBKR needs to send an object via for the monitored symbol.

Each partial fill for an order generates a separate object so that it is likely the condition triggers upon the first and possibly partial fill.

闯ü谤驳别苍

That is correct. There is a TWS API Global Setting that can eliminate the race condition for a large class of orders. It is called "Use negative numbers to bind automatic orders". When selected, automatic orders get bound to monotonously decreasing negative numbers and, therefore, will not interfere with the client's requirement of using monotonously increasing orderIds for new orders.

The remaining cases need to be eliminated by design. When several independent clients place orders in the same account, there is probably a need for coordination amongst them anyway (account margin management, avoiding opposing orders for the same instrument, ...)? so that one shared orderId assignment strategy could be used.

And the measure of last resort is monitoring the "Duplicate OrderID" error 103. The client could assign a new (higher) orderId and retry the placeOrder request.

闯ü谤驳别苍

Thanks for the very informative posts.I was looking into orderId recently and it solved my problem.One little comment about the following cited piece in the document.

However if there are multiple client applications connected to one account, it is necessary to use an order ID with new orders which is greater than all previous order IDs returned to the client application in openOrder or orderStatus callbacks.

I think it is inherently a race condition. Think about the situation that an orderStatus callback is en route from TWS to the master client while at the same time the master client is placing an order. In this event, there may be order id collision.