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.
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.