Crossposting here, as likely more appropriate place. Short recap of the prob: while submitting a bracket order via TWS API (main with two children), one of the children (stop loss) is not submitted (stays in the Inactive state), but the main order is submitted and can be filled, leaving unprotected position. The last order in sequence is submitted with m_transmit=true. Java API. Happens on live account. TWS Build 944.3c, API 9.70, but I have seen this with older versions too. From the API point of view it looks like this: after the last order is submitted, the openOrder() is called with the id of that last order, and then called once again with the id of the main order. It's not called with the id of the second order. In the case when IB processes such a bracket order correctly (which is approximately 4 out of 5 brackets), openOrder() is called properly with ids in reverse sequence: last, middle, main. By the way, this is the way to determine the bracket order was submitted ok. Another observation: the problem manifests if orders are executed from a US location, does not manifest if executed from a European location, that is has something to do with latency. Please note, this is a different from infamous (although probably related to) : Error code: 135, msg: Can't find order with id =x (when parent not found submitting child). In the discussed case the parent is submitted and accepted by IB, but a child is not. The Error code: 135 is not location specific, btw.
I set transmit=true on the stop order (and send it last). And false on the other two orders. That way the parent order doesnt go live unless the stop order is received properly. Add more memory and perhaps a faster (multi core) CPU PC. As i used to get the same corruption problem you had many years ago when i only had 1gb of ram. If your PC is heavily loaded running other processes when you are submitting orders that might also cause this problem.
Ok, thanks, southall, this is a nice workaround to get at least the stop there. If anyone at IB cares to look at this, I'll add, that in my case it's several Gb of free memory, and I run it on 2 cores with minimal CPU load. The issue happens on both Windows and Linux.
We made a change which will definitely fix the 135 error and may also fix this problem as well. I can't say for sure because I was not able to reproduce the exact symptoms you describe. The fix is released to beta in build 9460r. Please let me know if you continue to experience the problem after upgrading to this build.
IB, this problem re-appeared again as of 24 March 2015: The stop order as part of the bracket is sometimes silently dropped by TWS, thus leaving the entire position without any protection. You fixed this last time (almost a year ago and it has been working since then). It seems your server update from 03.24.15 broke it (maybe you forgot to reapply a patch or something). Pete - IB, please fix this!
All of my API brackets are still working normally, for whatever it's worth. Are you getting any kind of debug output (or reviewing the audit files) to see what's happening?
There is no audit. It manifests as openOrder() for the stop is not called back by the API. Only for the parent order. And the stop order is in fact not transmitted. Only the parent. Did you experience this problem in the past as outlined in the beginning of the thread, i.e. a year ago? Fortunately, IB knows about this problem as they provided a fix in the past. Now maybe this has been rolled back.
Upgraded to the latest 9554i from previously working 9542a. The problem appeared again. The previous version has been working fine for a half a year. @Pete - IB, can you please look into this and fix it for good?