Hear! Hear!
Gordon is right on and the only pointer I can add is the TWS API Guide chapter . It starts with:
When placing orders via the API and building a robust trading system, it is important to monitor for callback notifications, specifically for , changes, warnings, and to ensure proper operation. If you experience issues with orders you place via the API, such as orders not filling, the first thing to check is what these callbacks returned. Your order may have been rejected or cancelled.
TWS API is an asynchronous API that connects client applications to an entirely asynchronous trading world. Events take place whenever they do, no sequence or timing of events can be assumed, and, consequently, using "sleep" to synchronize events is absolutely unacceptable. And so is ignoring callbacks.
I wish IBKR support would eliminate "sleep" from their vocabulary and IBKR API engineering would remove the last few uses of sleep from TWS API. Our platform is entirely event driven and asynchronous, our client apps never use sleep, observe all callbacks and everything runs rock solid and fast. We have experimented with strategies that place/change/cancel several orders per second very reliably.
Another tool for managing orders that works very reliably is . It triggers much faster than when client applications manage cancellations themselves (even on networks with very low latencies).
´³¨¹°ù²µ±ð²Ô
PS. We also "over cancel", except in cases where TWS API already sent messages that confirm proper cancellation of all orders.
On Sun, Jul 23, 2023 at 08:29 PM, Gordon Eldest wrote:
In case you wonder, by the asynchronous nature of the API (which is good) you should never assume instantaneous execution.
Sending the request is just queuing and intent. (more about callback below) and I like it that way.
I check explicitly order status before an assumption like a cancel being done, in particular if I have to re-submit a substitute order. (or you have to factor-in the risk of parallel execution, which could make sens if time is critical)
I am not sure it's a good practice to rely on any sleep, the API is a state machine and you should track the state of it either trough additional IB request or internally or both. (both is good as order are the crucial part of the usage of the API)
here "both" means:
Listening to orderStatus callback is generally enough. "generally" because:? When the callback fires, I always find it accurate,
but in IB doc I read that at least in some cases of immediate execution the callback may not be called. The sentence imply that there is a gray area there and better have a "plan B"
It's a difficult area for doing accurate tests,? it is very much market dependent, so that "belt and suspender" are required.
So doing an additional explicit detail request is safe and generally fast enough in view of execution time, so I never study that part of the API again. It work.
you surely read it but just in case:
also helpful
About cancel sl/tp:
I do cancel them but don't know if its needed, because I prefer to "over cancel" applying the rule that everything that have an individual orderid could and maybe should be cancelled.
So as I track childs ID, a "cancel session" is made of cancelling everything related to the bracket and thanks to the async API that have no impact I can notice.
Surely need some study.
