Correct way for checking order errors.

[misova]

I would like to know, what is the correct way to check order errors in strategy.
(I am interested mostly in Unmanaged mode, but maybe there is no difference with Managed)

I am mostly interested in handling most common problems like these 3:

• ErrorCode.UnableToCancelOrder
• ErrorCode.UnableToChangeOrder
• ErrorCode.UnableToSubmitOrder

Is it good approach to check until OrderState.Rejected is detected and only after then investigate the error variable?

Or should I check the error variable everytime and everywhere I do something with order? I hope not - and there is some mechanism, that notifies, that something is wrong with the Order.

Or is there some another recommended approach?

The problem is - that I cannot see the big picture of handling errors - how it is designed to be done under common circumstances.

I see 2 channels, that can report some potential problem, but do not see the relation between the OrderState(s) and Order#error..

• 1. some problems with Order can be detected from OrderState (like OrderState.Rejected or OrderState.Unknown)
• 2. some problems with Order can be detected Order#error variable.

Are the 2 abovementioned ways of reporting problems completely unrelated or is there some direct relation? - for example like: "if Order gets into State.Rejected or State.Unknown -> then variable error should be investigated for more details about the problem."

I just cannot imagine, that evewhere and everytime we interact with Order, we should investigate potential problems. It should work like we do not need to look for problems with Order, until we are notified about the problem.

[NinjaTrader_DaveI]

Hello,

It sounds like you have a firm grasp on how it works. OrderState is used to track the state of orders from placement all the way through being filled, cancelled, or rejected, but it is not going to provide detailed information on specific errors occurring for the order. The closest that you will get, as you noted, is OrderState.Rejected.

If you would like to figure out why an order was rejected, then the process you propose would be the best way to go about it. I recommend checking for OrderState.Rejected, and when it is detected, then drilling down into ErrorCode to find out why. I cannot see a reason to check ErrorCode on an order which was submitted and filled (or cancelled by user) with each update, as I would presume in this case that no errors were encountered. What I would recommend is to test for OrderState transitions that you expect, and check ErrorCode if things are not going as you expect.

[bltdavid]

What I would recommend is to test for OrderState transitions that you expect, and check ErrorCode if things are not going as you expect.

In my opinion, this is not the best advice.

Check for error codes independent of state.

https://www.dropbox.com/s/cvflui3o43evonj/IMGDT_20160229_201757.jpg?dl=0

See above screenshot showing UnableToChangeOrder errors in my NinjaTrader log; the errors are returned despite OrderState being set to Working or Accepted.

Today, I was executing same exact strategy on 3 different charts on 3 different accounts (2 Topstep accounts and 1 live brokerage account, all charts were 4-Range) and price started to really move. Now, with range bars, when price really starts to move, it seems a lot of bars (even phantom bars, created to fill price gaps) can be created very quickly.

See the markups in the above screenshot.

The autotrail code in my strategy tried to move the stop order, but the attempt to set the stop price to 33.87 (see PendingChange order above it) failed due to price whipsawing so much that current price was now below 33.87 at the exact moment the NT tried to change the order.

How is this "failure to change price" reported?
Is it reported via OrderState or via ErrorCode?
Easy. It is reported via ErrorCode, the OrderState never reveals that a problem just occurred.

What happens is this:
The UnableToChangeOrder error is reported in the next state change of PendingChange to Accepted or Working, but price remains at the previous value of 33.77 (since the PendingChange to 33.87 could not succeed).

The point is: an error is reported inside ErrorCode despite a relatively normal state transition from PendingChange to Accepted/Working.

The moral is: Don't rely on expected transitions to have worked without error. Check the ErrorCode regardless.

My experience today was new, and quite interesting. I'm updating my strategy's order mgmt code to better check ErrorCode regardless of OrderState.

I think I understand what must have happened under the hood, though I'm not sure I've seen it documented. There is an OrderState change diagram in a thread somewhere that a poster put together -- it was pretty awesome. I may have to go find that.

I'd like NinjaTrader to comment on this:
The different between OrderRejected and UnableToChangeOrder is (I suspect) one of pre-existance. A brand new order with SubmitOrder can easily be set to OrderState.Rejected. But pre-existing orders cannot be changed "back" to Rejected, because a pre-existing order in OrderState.Accept or OrderState.Working stays in those states and the error is reported via ErrorCode. Is this correct?

I mean, can an already existing order in state Working/Accepted ever be changed to OrderState.Rejected? I think the answer must be no. Think of an auto trailing stop order that already exists, and is in state Accepted or Working: if the price cannot be changed by the ChangeOrder() function, the OrderState does not change to Rejected, but the error is reported as UnableToChangeOrder. Is this correct?

[Edit: uploading jpg files appears to be broken]

[NinjaTrader_ZacharyG]

Hello bltdavid,

We are currently investigating this further.

Thank you for your patience.

[NinjaTrader_DaveI]

The way the order states would change in this scenario will depend on the specific provider's API. In most cases, and existing order acted upon by ChangeOrder() would not go to rejected. Instead, it would go from Accepted or Working to PendingChange, and when the change failed, it would then move back one step, from PendingChange back to Accepted or Working. Thus, in most cases (again dependent on the API), only an order which had not already reached Accepted or Working could be changed to Rejected.

[bltdavid]

... only an order which had not already reached Accepted or Working could be changed to Rejected.

Yes! Yes!

Touchdown! I win!

Ahem. I mean ... cough cough ... if it would please the court ...

Uh, by pre-existence, what I really meant was the order must first reach Accepted or Working, after which it can no longer be Rejected.

Cough cough ...yeah, yeah, that's the ticket.

That's what I meant to say.

Therefore, your honor ... cough cough ... uh, beg pardon?

Case closed? I won?

Yes! (fist pump)

[koganam]

Yes! Yes!

Touchdown! I win!

Ahem. I mean ... cough cough ... if it would please the court ...

Uh, by pre-existence, what I really meant was the order must first reach Accepted or Working, after which it can no longer be Rejected.

Cough cough ...yeah, yeah, that's the ticket.

That's what I meant to say.

Therefore, your honor ... cough cough ... uh, beg pardon?

Case closed? I won?

Yes! (fist pump)

Hey, pipe down friend! Now on to squash the next bug. There shall be no rest for the weary.

[bltdavid]

There is an OrderState change diagram in a thread somewhere that a poster put together -- it was pretty awesome. I may have to go find that.

Found it:

http://ninjatrader.com/support/forum/showthread.php?t=73565