Support Board
Date/Time: Fri, 29 Nov 2024 02:44:19 +0000
Post From: canceled stop order continues to have status SCT_OSC_OPEN
| [2023-02-19 18:34:01] |
| Berliner JFK - Posts: 45 |
|
I will do my best to explain. Here is what the ACSIL code does: 1. first a stop order is placed 2. at some later time the stop order is canceled 3. right after canceling the stop order, the code searches the trade order list (see code in first post) using the criteria "SCT_OSC_CANCELED" in order to confirm that the stop order is in fact canceled. This is a double-check and the code always finds the order ID that was just canceled. This is the expected behavior and is not the problem. 4. right after searching the trade order list for the canceled order, the code also searches it for any open stop orders using the criteria "SCT_OSC_OPEN". This is a double-check to ensure that any open stop orders still match the stop orders that the code expects are still open. Here is where the problem happens. When the trade order list is searched for open orders using the criteria "SCT_OSC_OPEN", it finds the order that was just canceled. That is, the order that was just canceled can be found using both the criteria "SCT_OSC_CANCELED" and "SCT_OSC_OPEN", meaning that it is in the trade order list twice, once as canceled (expected) once as open (not expected). I found a potential clue today. If a disconnect / reconnect is performed between trades, this seems to solve the problem.
If a programmatic disconnect / reconnect (sc.ReconnectToExternalServiceServer = true) is performed right after canceling the stop order, but before searching the trade order list, the canceled stop order no long shows up as "SCT_OSC_OPEN", rather only once as "SCT_OSC_CANCELED" as expected. I hope that helps. Thanks! |