Cancelled Pending Orders - not cancelling and being stuck

[kenconcannon]

I have a strategy running in unmanaged mode. On occasion, the order state on an order which is being cancelled gets stuck at "Cancelled Pending". If I look at the orders tab in the control center that status of the order stays at "Cancelled Pending". When I disconnect the connection and reconnected the order state is "Accepted".

Is there any way to force the cancel if the order state is stuck in cancelled pending? How should I handle? Disconnecting and reconnecting the session to read the order state seems to be a poor solution

[NinjaTrader_Jesse]

Hello kenconcannon,

There is not a way to force a cancellation, if the action you are doing results in the order becoming stuck you would have to review the cancellation logic and make sure that is only happening while the order is in a working state. If you are cancelling an order when its only been submitted that may result in the order becoming stuck.

[kenconcannon]

I will make sure it cancels only when in an Accepted or Working State. It seems to only happens when there is a larger amount of orders (20-30+) on the connection. Should I throttle the cancels?

[kenconcannon]

One other item - it is happening in unmanaged mode when the following command is executed::

Account.Flatten(instrumentsToFlatten);

The reason I am using the flatten command is because in an unmanaged mode there doesn't seem to be another option to close the position (other than adding an opposing market order in the opposite direction).

if i use a CancelOrder, i can check the state of each order prior to individually cancelling each order but that doesn't take care of the existing position

[jeronymite]

kenconcannon If you keep track of and manage all orders individually, you can choose how you go flat from a number of possibilities, including the use of Account.Flatten, and also Cancelling of each individual order, and submitting equivalent orders in the "opposite" direction to exit positions. It's important to closely monitor the results and cater for all possible events including, for example, orders that fill before an already-submitted Cancel can be executed. There's also the potential for rejected orders during exits, and, depending on the broker's trade management, the possibility of margin issues on orders designed to exit open positions. Account.Flatten may be the simplest for initiating the process of a full exit to flat, but it still needs monitoring and confirmation of the results to ensure it worked as expected.

My own AddOn handles up to 2296 contemporaneous orders in a single "trade" and can manage those large numbers of orders (filled and yet-to-fill) reliably. It's not a numbers thing so much as a precise process with good contingency handling when it doesn't quite do what is expected/required.

The issue of orders stuck in CancelPending, however, is another matter entirely, and there is much to read about that:

• https://forum.ninjatrader.com/forum/...d-be-deletable
• https://forum.ninjatrader.com/forum/...n-sim-accounts
• https://forum.ninjatrader.com/forum/...losing-out-nt8
• https://forum.ninjatrader.com/forum/...-please-advise
• https://forum.ninjatrader.com/forum/...er#post1191488

Thanks.

[kenconcannon]

jeronymite Thanks for the info - it is very helpful. The only problem I am having is some orders being stuck in the CancelPending state (ninjatrader obviously thinks it has sent the request to the broker but the broker still thinks the trade is Working or Accepted).

The reason I was mentioning the Account.Flatten() method is because I was wondering if there are a large amount of orders being processed, is the flatten command checking to see if the order is in a terminal state prior to cancelling - just trying to find a reason why this is happening.

I am actually working with an AddOn (not a strategy) and I am going to put a process in place to disconnect and reconnect the connection if the orders appear stuck. The AddOn is intended to run unattended so the stuck CancelPending orders are concerning.

I am also considering not using the account flatten command and just processing the orders individually where I can verify the state and possibly throttle the cancels to the broker as the issue only seems to occur when there are a large amount of cancels happening (40-50+). If the are a smaller amount of orders being cancelled this is not an issue.

My process utilizes an order cache (list) that is maintained through the OnOrderUpdate method.

[NinjaTrader_Jesse]

Hello kenconcannon,

If you are using an addon and not a strategy the Account.Flatten method can be used. In a strategy managed or unmanaged that would not be expected but it would instead be expected that you track and cancel the orders using CancelOrder. An Addon also would generally use account.Cancel in most situations so it can control the orders that it tracks specifically. The addon cancel method takes an array of orders so you should be able to pass your whole list of orders to that method if you wanted.

https://ninjatrader.com/support/helpGuides/nt8/cancel.htm

Tracking the orders directly gives you the ability to avoid corner cases like the order had filled before you try to cancel it, you would generally use OnOrderUpdate to update your order variables to null when they fill or are cancelled to prevent other logic from doing conflicting actions.

It would not be expected for an order to get stuck in pending cancel on a live account because the broker is ultimately pushing the state of the order to the platform but that can happen on a sim account when you have logical conflicts. Stuck orders can be seen when race conditions are encountered with the Simulation Engine, I.E. order fills and cancellations occurring at the exact same time or near the same time. There is no additional state that can happen at that point which requires resetting the database in most cases.

The AddOn is intended to run unattended so the stuck CancelPending orders are concerning.

Just to briefly comment on this topic, we never suggest leaving a script running on a live account completely unattended as there can be unforeseen problems that could end up costing actual money at that point. Its always suggested to monitor what the script is doing so you can take action when needed.

[Trader17]

Hello kenconcannon,

If you are using an addon and not a strategy the Account.Flatten method can be used. In a strategy managed or unmanaged that would not be expected but it would instead be expected that you track and cancel the orders using CancelOrder. An Addon also would generally use account.Cancel in most situations so it can control the orders that it tracks specifically. The addon cancel method takes an array of orders so you should be able to pass your whole list of orders to that method if you wanted.

https://ninjatrader.com/support/helpGuides/nt8/cancel.htm

Tracking the orders directly gives you the ability to avoid corner cases like the order had filled before you try to cancel it, you would generally use OnOrderUpdate to update your order variables to null when they fill or are cancelled to prevent other logic from doing conflicting actions.

It would not be expected for an order to get stuck in pending cancel on a live account because the broker is ultimately pushing the state of the order to the platform but that can happen on a sim account when you have logical conflicts. Stuck orders can be seen when race conditions are encountered with the Simulation Engine, I.E. order fills and cancellations occurring at the exact same time or near the same time. There is no additional state that can happen at that point which requires resetting the database in most cases.


Just to briefly comment on this topic, we never suggest leaving a script running on a live account completely unattended as there can be unforeseen problems that could end up costing actual money at that point. Its always suggested to monitor what the script is doing so you can take action when needed.

You are correct. You can never ever trust NT8 100% of the time. In a world of milli and nano seconds there is always the possibility of something happening first that was supposed to follow something instead.