Add-On Framework Order -- Rejection Handling Caused Serious Adverse Effects

[lunardiplomacy]

Hello,

Today I had to make a call to the emergency trading desk because an error in rejection handling on my part caused repeated orders to be submitted. In hindsight it was unwise of me to deploy this code into live markets after only a few tests appeared to demonstrate expected behavior.

Below is the problem code...

if (e.OrderState == OrderState.Rejected)
{
if (e.Order.IsLong)
{
Order remedyLong = null;

TriggerCustomEvent( o =>
{
remedyLong = myAccount.CreateOrder(Instrument, OrderAction.Buy, OrderType.Market, OrderEntry.Manual,
TimeInForce.Day, quantity, 0, 0, "", "remedyLong"+DateTime.Now.ToString(), DateTime.MaxValue, null);

myAccount.Submit(new[] { remedyLong });
}, null);
}
else
{
Order remedyShort = null;

TriggerCustomEvent( o =>
{
remedyShort = myAccount.CreateOrder(Instrument, OrderAction.Sell, OrderType.Market, OrderEntry.Manual,
TimeInForce.Day, quantity, 0, 0, "", "remedyShort"+DateTime.Now.ToString(), DateTime.MaxValue, null);

myAccount.Submit(new[] { remedyShort });
}, null);
}
}

This is all occurring within OnOrderUpdate of course. The main strategy checks that a condition is true and submits a stopmarket order on the first tick of the next new bar. If the market moves faster than the main strategy is able to handle then rejection handling comes in to submit a market order to take the place of the failed stopmarket order. This is what you see above.

If anyone could offer insight as to why what happened today happened and what I can do to fix it I would be really appreciative. I want to be up and running with my code as soon as possible. I know the reference page for add on orders even says implementing them improperly has the ability to wreck your account, I wish I had taken a beat.

A related but much less important issue I'm having is that whenever I try to change parameters in the Indicators interface for this code I get an error that the Calling Thread Cannot Access the Object Because a different thread owns it. Is this an issue with the dispatcher i'm using to create the grid in the same script? if needed i will post instances where i am using a dispatcher.

Thank you everyone!

[NinjaTrader_Jesse]

Hello lunardiplomacy


From the given code I can't really tell what problem you had aside from what you described that there was a rejection and then the logic was allowed to continue resubmitting orders. If there was a rejection and it was not handled correctly that would really be where you need to start or identify what specifically happened to cause that rejection. Generally rejections will come with a reason, you can look in the log at the time that happened to see what is noted about it. Once you have those details you can work to either try and avoid the rejection to start with or change the handling to match the scenario.

A related but much less important issue I'm having is that whenever I try to change parameters in the Indicators interface for this code I get an error that the Calling Thread Cannot Access the Object Because a different thread owns it. Is this an issue with the dispatcher i'm using to create the grid in the same script? if needed i will post instances where i am using a dispatcher.

If you are getting an error when you try to access the indicator parameters that likely is caused by some code in OnStateChange. That would relate to something you are doing with the user interface.

[lunardiplomacy]

Hi jesse,

Thanks for getting back to me, in my trace files I see the initial stop order was "RejectedByFCM", which then i'm assuming triggered my rejection handling logic, and all of the market orders submitted were "RejectedByGateway".

I think the actual reason for the initial rejection was that the market had moved below the stopMarket sell (which is why i have the rejection handling send a market order as a remedy for this).

As I said, the logic is triggered by OnOrderUpdate, my understanding is that the code above should only execute once at the first detection of a rejected order. I wish i knew what "rejectedbygateway" meant because I think what happened is that the initial order was rejected for the reason stated above, and then the remedy market order that was sent by my logic above was ALSO rejected, thereby triggering a loop which ultimately crashed my instance of NT8.

Does this help you at all to provide a potential solution? is there a way i can ensure that the rejection handling is only triggered once (i thought i had accomplished this by putting the logic in OnOrderUpdate) and perhaps even more specifically be limited in scope to when the market moves too quickly for the stop order to be placed?

Thank you again for you response, I look forward to any insight you may have on what rejectedbygateway means and how i can prevent further issues with this logic.

[NinjaTrader_Jesse]

Hello lunardiplomacy,

For the rejections you would likely want to contact your broker to collect the specific details surrounding those specific rejections, that could help you to better isolate how that affects your code. The error codes you provided only lets me know that it was rejected, I don't have any specific details on what may have created those type of rejections.

As far as a solution you would first need to check on the rejection reason and depending on how that was caused you may be able to simulate that on Sim101 to fix it.

Putting the code in OnOrderUpdate would be the correct location for rejection handling code, OnOrderUpdate is called many times which represent all order events. If you see that there were multiple rejections or messages provided then you may see that is called for each event. Just like when submitting orders you would need to add any additional logic needed to make sure the rejection handling code works exactly as you expect. Using Prints would be the best suggestion to see how frequently that code is called in the given use scenario.