Target Order of OCO orders continues to execute instead of being canceled.

[ntbone]

Not yet. I am able to easily reproduce the problem using the simulator itself and place orders using the chart trader. Have given this information to NinjaTrader but not yet heard back from them.

[shadowfax]

hello - was this ever resolved? i am getting a similar behavior using SetProfit and SetLoss - always executes beyond original quantity and goes short (for a long position). i have recreated (occasionally) in sim but haven't fixed the issues yet.

[ntbone]

I have tested the code on months and months of playback data, both using downloaded historical data and recorded live data. It has never reproduced in playback. It has reproduced now dozens and dozens of times with a delayed live data feed. I have also specifically tried to execute known trades that produced the problem in the live data in playback of the exact same day without any issue, even if I leave the playback speed at 1x.

I have submitted an email with the code as well as a sample log showing the reproduction.

I do not know how to get the simulated data feed to reproduce the problem. The issue is that the price needs to move from the target order to the stop order before completely filling either one. This requires the price move very quickly and fast in order to trigger the issue.

[NinjaTrader_Jesse]

Hello ntbone,

If you form a sample you can send it to platform support [at] ninjatrader.com. We would need the specific steps you used to reach the result and please ensure to simplify the code as much as possible. We cannot debug scripts for you but we can intake examples of problems to better understand the issue or to form bug reports.

If it takes multiple days to see the problem that may not be something our support can test, I see that you posted you were unable to see this in playback, could you re that again to make sure? If the playback can demonstrate this at all that would be a best case scenario so that we could confirm it and write up the specifics/see if that is expected. If you otherwise can see this using the Simulated data feed at all that would also be another best case scenario, if trending the market in a certain way is part of the steps that is fine we would just need to know that. Relying on incoming real data is inconsistent so that can be more difficult to replicate, if you can please experiment on multiple different instruments to see if one of them can more readily demonstrate the issue at a faster rate.

If you otherwise mean your condition may take several days to place an order, please try making a more refined sample that places an order immediately in realtime or a similar type of test. We only would need to see one occurrence of the problem, having the ability to re test the problem after seeing it would also be very helpful.




I look forward to being of further assistance.

[ntbone]

I believe I have code that demonstrates the problem. It may take several days of running before it happens but it will eventually trigger. Where would I send the code when ready?

[NinjaTrader_Jesse]

Hello ntbone,

I reviewed the updated info here however we would still need some kind of sample of the logic you used and steps used to continue looking into this. From the given details I couldn't say what may be happening in your test other than this somehow relates to the logic and orders being used.

We can start by looking into a specific sample of the logic that causes this result to see if that would or would not be expected based on the logic used. Without that information it would be a guess as to why you are reaching that outcome.


Please let me know if I may be of further assistance.

[ntbone]

I have a second scenario. This scenario is simpler

• Entry Order
• OCO Stop and Target Order

In this case all orders are for the same quantity. Quantity is large enough it takes several executions to fill the order.

A similar scenario happens again.

1. Entry fills completey
2. Target fills partially
3. Stop is updated
4. Stop fills fully
5. Target goes to canceled state => working => partially filled.

After this, the target order is left open and active and the order refuses to go away whether its with API calls to cancel it, or canceling it through the various means of the UI. I discovered that if I click on the quantity of the order and change the quantity, the order is no longer active. Analyzing the logs, this action of changing the quantity puts it in a filled state making it no longer active.

Both problems have a the similar pattern in common

• OCO orders and its the target ( a limit order) that ends up with the issue.
• The target is partially filled, the stop is fully filled.
• The target goes to canceled, but then back to accepted and then into some state of working. It may just sit there, it may continue to get filled.

Note: The live connection is to the delayed data feed from Kinetick. I can't imagine the delay would make much of a difference but its there.

[ntbone]

I am still hitting this problem on a somewhat regular basis. I have yet to be able to reproduce it outside of a live simulated trading. The logs show me the same behavior as I described above. I can provide several log examples of the situation.

My understanding with an OCO is that as either the target or the stop order are updated, the other one would be reduced by the respective quantity. This seems to happen most of the time, but every so often

1. The target fills partially
2. The OCO stop fills fully.
3. The independent stop fills fully.
4. The target goes to cancel pending, then back to working and finishes filling itself with whatever quantity it didn't complete.

The sample above doesn't use the Account.CreateOrders, Account.Submit, etc... which is the API I am using as the code executing trades is part of an Addon and not a strategy.

Separating the entry order out into two pieces does not change the outcome here. The entry orders fills to completion and are out of the picture before the target and stop orders begin working.

I looked at the timing of the orders for a few examples. Stop 1 happens, some time passes, then steps 2, 3, and 4 all happen in under a second. Some keys to this situation happening are

• The execution happens fast, in under a second
• The instrument price fluctuates from the target price to the stop price and then back to the target price rather quickly. The target and stop prices are not close.
• The quantity desired is large enough that it can, at times, take several executions to fill an order.

My understanding is that working with an actual broker, more time would be taken between submission and execution, and that the broker is responsible for executing the OCO group. That said I am still concerned with the very undesirable behavior. This instability needs to be resolved before the Addon could be used in a simulated setting.

[NinjaTrader_Jesse]

Hello ntbone,

The only other details I can provide with the given information is that is the suggestion given in the help guide sample for scaling out of a position. If you are submitting multiple targets for an entry and scaling out, that is what is suggested in the reference sample we provide. There have otherwise not been enough details provided for me to accurately say here. If you can provide a specific sample/steps which demonstrates the problem we can also look further into that. If using oco is otherwise getting in the way of what you are trying to do, that is generally a case which you can instead avoid using oco and use custom logic/the order events instead to handle that use case.


Please let me know if I may be of further assistance.

[ntbone]

Can you provide more information as to why I would need to separate out the entry into two pieces? If I were to scale the position to now 200 units instead of 100 would I not possibly seem the same problem again? For every case I have investigated there have been some common attributes.

• The initial entry order fills in pieces, does not fill all at once.
• The limit order fills partially
• The stop order fills the rest.
• The limit order goes to canceled but doesn't complete.

If I were to change my units to 200 units and divide up the entry into pieces as you described, I would end up having orders execute with the common attributes above and still see this problem occurring.

Further, separating them out complicates the code for managing the orders and limits flexibility of future decision making. It is not necessarily known in advance how a given entry might be split up. Conditions could arise that change how the shares would be divided.

I would like to understand why an OCO order that is canceled goes back to a working state instead of canceling out as it should.

[NinjaTrader_Jesse]

Hello ntbone,

Thank you for the reply.

From reviewing the question again, I can say that it is not suggested to use two targets for a single entry when scaling out of a position. It would likely be suggested to create two entries of 50 quantity each in this case to avoid having two separate exits tied to a single entry. We have a sample using the managed approach which shows the correct way to scale out of a position here: https://ninjatrader.com/support/help...a_position.htm

For the described use case if you didn't want to submit multiple entries, you would likely need to just use logic and cancel the order which needs to be stopped based on the order events seen by the script.






Please let me know if I may be of additional assistance.

[ntbone]

This continues to happen during live trading, but never reproduces when testing the specific problematic trades on playback. The playback timing/filling must be slightly different from a live feed. It happens about the same way every time.

1. A limit and stop order are paired together as an OCO
2. The limit/stop both partially fill until the position is closed.
3. The limit order goes from "cancel submitted" to "working" and then to "Partially filled" and finishes filling out instead of canceling.

I have a filtered log capturing all the events that I can provide by email if that helps at all.

[NinjaTrader_Jesse]

Hello ntbone,

Thank you for the post.

From the provided details nothing specific sticks out which may be the problem. If you are able to produce a simplified example of the logic you are using and the steps to see the problem, we can take a closer look into that case.

Please let me know if I may be of additional assistance.

[ntbone]

Orders are created and executed as follows

1. Entry order for 100 shares is fully filled.
2. Once filled, a pair of orders is created for 50 of the shares. One of the orders is a stop order and one is a limit order. They are paired with an OCO. A second stop order is created for the other 50 shares.
3. The limit order partially fills (say 5 shares) and then the stop order fills for the remaining. The other stop order also fills completely. The account goes to a position of 0.
4. The limit order goes to a state of accepted, then cancel submitted, but then proceeds to go to a state of working, partially filled and filled. It then fills for some remaining amount of the shares.

This has happened 3 times so far in testing with a simulation account using live market data. I have yet to be able to reproduce it via market replay of the live data.