I would like a clear and unambiguous explanation of the circumstances that trigger these two events.
From the OnOrderUpdate documentation, this appears:
What "adverse" actions could change once an Order state is filled in OnOrderUpdate??
Empirically (from the Log) I see that an order submitted by a strategy to, say, open a Long ES position for two contracts causes TWO OnExecutionUpdates after a series of OnOrderUpdates (if I can believe that things are logged in the order they actually occur), and the ExecutionOrder.Order.OrderState for BOTH OnExecutionUpdate events is OrderState.Filled, even though at the strategy level only ONE order was submitted. If the top level order has been split, I was expecting that the first OnExecutionUpdate ExecutionOrder.Order would have an OrderState of PartFilled, but that seems not to be the case.
Other documentation states that the return of the Order object from the Submit order cannot be relied on until it is set in OnOrderUpdate.
So can the Order object, if set in OnOrderUpdate, be relied on in OnExecutionUpdate? I want to when I can rely on the OrderState in the Order, so that I know how to update internally (within the strategy) privately managed position objects.
Thanks.
From the OnOrderUpdate documentation, this appears:
Critical: If you want to drive your strategy logic based on order fills you must use OnExecutionUpdate() instead of OnOrderUpdate(). OnExecutionUpdate() is always triggered after OnOrderUpdate(). There is internal strategy logic that is triggered after OnOrderUpdate() is called but before OnExecutionUpdate() that can adversely affect your strategy if you are relying on tracking fills within OnOrderUpdate().
What "adverse" actions could change once an Order state is filled in OnOrderUpdate??
Empirically (from the Log) I see that an order submitted by a strategy to, say, open a Long ES position for two contracts causes TWO OnExecutionUpdates after a series of OnOrderUpdates (if I can believe that things are logged in the order they actually occur), and the ExecutionOrder.Order.OrderState for BOTH OnExecutionUpdate events is OrderState.Filled, even though at the strategy level only ONE order was submitted. If the top level order has been split, I was expecting that the first OnExecutionUpdate ExecutionOrder.Order would have an OrderState of PartFilled, but that seems not to be the case.
Other documentation states that the return of the Order object from the Submit order cannot be relied on until it is set in OnOrderUpdate.
So can the Order object, if set in OnOrderUpdate, be relied on in OnExecutionUpdate? I want to when I can rely on the OrderState in the Order, so that I know how to update internally (within the strategy) privately managed position objects.
Thanks.
Comment