Backtest NT managed orders are left in state working when reversing position.

[MojoJojo]

Hello,

here is a demonstration of the rare but still existing case where NT gets confused and does not either cancel or fill an order during backtesting with managed positions.
This happens when reversing a position and stop/profit takers are set that will also result in a fill.
It doesn't make or break a system but it's still a bug.

In my example I am using 10000 vol bars on CL starting from 01/Jan/2020 non merged and 10 fast 259 slow(times are in EST). If it helps I can supply as many bar/parameter combinations as necessary for reproduction with exact dates.

    public class SampleMABracket : Strategy {
        private SMA smaFast;
        private SMA smaSlow;

        protected override void OnStateChange() {
            if (State == State.SetDefaults) {
                Description = "Sample MA Bracket";
                Name = "SampleMABracket";
                Fast = 10;
                Slow = 25;
                // This strategy has been designed to take advantage of performance gains in Strategy Analyzer optimizations
                // See the Help Guide for additional information
                IsInstantiatedOnEachOptimizationIteration = false;
            } else if (State == State.DataLoaded) {
                smaFast = SMA(Fast);
                smaSlow = SMA(Slow);
            }
        }

        protected override void OnBarUpdate() {
            if (CurrentBar < BarsRequiredToTrade)
                return;

            if (CrossAbove(smaFast, smaSlow, 1)) {
                if (Position.MarketPosition != MarketPosition.Long) {
                    SetStopLoss(CalculationMode.Ticks, 30);
                    SetProfitTarget(CalculationMode.Ticks, 30);
                    EnterLong();
                }
            } else if (CrossBelow(smaFast, smaSlow, 1)) {
                if (Position.MarketPosition != MarketPosition.Short) {
                    SetStopLoss(CalculationMode.Ticks, 30);
                    SetProfitTarget(CalculationMode.Ticks, 30);
                    EnterShort();
                }
            }
        }

        #region Properties
        [Range(1, int.MaxValue), NinjaScriptProperty]
        [Display(ResourceType = typeof(Custom.Resource), Name = "Fast", GroupName = "NinjaScriptStrategyParameters", Order = 0)]
        public int Fast { get; set; }

        [Range(1, int.MaxValue), NinjaScriptProperty]
        [Display(ResourceType = typeof(Custom.Resource), Name = "Slow", GroupName = "NinjaScriptStrategyParameters", Order = 1)]
        public int Slow { get; set; }
        #endregion
    }

[NinjaTrader_PaulH]

Hello MojoJojo,

Thanks for your post.

It is possible that Historical overfills can occur in managed approach strategy when 3 orders are filled in the same bar.

Please repeat the test with strategy analyzer's High order fill resolution set to 1 tick.

[MojoJojo]

Hello Paul,

thank you for acknowledging the bug and your advice how a user should deal with it.

The discerning eye notices that 3 fills on 2 bars happened(but you are right it only looks like it in the chart but not in the log) and that the third order gets the system long. However NT never closes the position an continues as if nothing happened from then on.

I don't want to exaggerate this bug's importance, it rarely ever happens but it does occur and has an impact. I only noticed it after writing code to verify NT's trade management, luckily most other users will never find out.

Coming from the team lead I am assuming this represents NinjaTrader's official solution to the problem.

[NinjaTrader_Jim]

Hello MojoJojo,

Historical overfills can happen with Standard Fill Resolution and it is a known limitation. Since the bar data is used to fill the orders, there is a wider range for where the orders can fill. We can encounter cases where one bar fills multiple orders at once which then causes the historical overfill.

This is seen when using non-OCO orders and when using Standard Fill Resolution. I.E. if we use Enter/Exit methods by themselves or in combination with Set methods.

Submitting orders to a single tick data series, or using High Order Fill Resolution will have the orders filled with intrabar granularity so the issue would be far less possible to hit.

Using native OCO with the Unmanaged Approach can work around, as well.

Improving this for Standard Fill would involve a lot of work changing fragile code, and since there are workarounds, this matter is left for now and we are tracking the impact. I have noted your impact with our tracking ticket SFT-2778.

Let us know if you have any additional questions.

[MojoJojo]

Hello Jim,

thank you for expounding on the subject and creating a ticket.

The positive side of my test is that with the rare exception NT's order simulation is reliable.

Having completed the test new capabilities unlock for me for backtesting strategies in conjunction with the platform.