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.
´³¨¹°ù²µ±ð²Ô
On Mon, Nov 6, 2023 at 10:38 PM, Little Trader wrote:
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.
