New bar detection in EAs: the bug behind doubled or missing signals

[Fairman]

New bar detection in EAs: the bug behind doubled or missing signals

Most EAs that trade on bar closes need to know when a new bar has started. The common approach is storing the time of the last bar and checking on each tick whether the current bar's open time has changed. Simple, but it's a classic source of bugs.

Doubled signals happen when the stored time isn't updated correctly, or is reset when the EA restarts. The EA sees the same bar as new twice and trades twice. Restarting the platform mid-bar is a common trigger.

Missing signals happen when no tick arrives at the start of a bar for a while, especially on quiet pairs or at odd hours. The EA only finds out about the new bar when a tick comes in, which might be well into the bar. If the logic depends on acting at the bar open, it's late.

Timeframe mismatches cause their own trouble. If the EA checks for a new bar on the chart timeframe but the signal uses another timeframe, it might evaluate the signal at the wrong time.

What helps: store the last bar time as a global variable or in a file so it survives restarts. Check the bar time of the specific timeframe the signal uses. And log every time the EA detects a new bar, so you can verify it's doing what you expect.

[Fairman]

In MT5, iTime with the symbol and timeframe gives you the open time of a specific bar on any timeframe, which makes multi timeframe new bar checks straightforward. Comparing that with a stored value is the usual pattern. Using the chart's own timeframe by default is where people get caught when they later attach the EA to a different chart. Passing the timeframe explicitly makes the EA behave the same regardless of which chart it's on. It's a small change that saves a lot of confusion later. It removes a whole class of surprises.

[Fairman]

Testing this is easy in the visual tester. Run the EA on a few days of data with a print statement every time it detects a new bar, and compare the log with the chart. Then stop and restart the test partway through, if your setup allows it, to see whether restarts cause a second detection. These are boring checks, but bar detection sits underneath every signal, so a bug there quietly affects every trade the EA makes. If a test shows the EA detecting the same bar twice after a restart, that's the bug to fix before anything else.

[FXS Prop Desk]

Storing the bar time in a global variable is the standard approach, but problems appear when the EA restarts and the variable resets. On restart, the EA thinks a new bar has started and may fire a signal immediately.

Initialising the variable to the current bar time in OnInit avoids that. Another issue is the first tick of a new bar arriving late in quiet markets, which is normal and should not be treated as a missing bar.

[Fairman]

Restarts are a common source of this bug. When the EA is reloaded, the variable storing the last bar time resets, and the EA might treat the current bar as new and fire a signal it already acted on. Storing the last processed bar time in a global variable of the terminal, or a file, avoids that. On restart, the EA reads the stored time and only acts on genuinely new bars. It's a few lines of code but prevents duplicate trades after a VPS reboot or a platform update.

[Fairman]

Another edge case is the weekend gap. When the market opens on Sunday, the first bar might have a time that's much later than the last Friday bar. If the EA calculates something based on the time difference between bars, like a timeout, the weekend can trigger it unexpectedly. Checking the logic around the first bar of the week in the visual tester, specifically, catches these. It's easy to test only on weekdays and miss what happens at the open, which is often exactly when you're not watching. Running the visual tester across a few Sunday opens is enough to check.