Eight Session-Boundary Tests I Run Before Trusting a Trading Bot

Arnold Holm — Sat, 15 Aug 2026 01:56:19 +0000

A session reset looks simple until a platform reloads data, reconnects or sends the same timestamp twice.

If a bot resets state from the calendar date alone, a restart can unlock a risk control early. Or the same session can reset twice. I keep two facts separate before I touch entry logic:

a new bar
a new trading session

Most new bars are not session starts.

A small classifier first

The first pass can be read-only. It receives the current timestamp and the platform's native session marker. It returns one observation class:

Observation Classify(DateTime current, bool nativeSessionStart)
{
    if (!hasPrevious)
    {
        previous = current;
        hasPrevious = true;
        return Observation.First;
    }

    if (current < previous)
        return Observation.Reordered;

    if (current == previous)
        return nativeSessionStart
            ? Observation.DuplicateSessionMarker
            : Observation.Duplicate;

    previous = current;
    return nativeSessionStart
        ? Observation.NewBarAndSession
        : Observation.NewBar;
}

This does not decide when trading is allowed. It only makes platform events observable. The business reset stays separate.

The eight tests

First observation. Initialize without inventing a previous bar.
Forward bar. Advance once without a session event.
Duplicate update. Keep state when the timestamp has not changed.
Duplicate session marker. Suppress the same marker at the same timestamp.
Reordered data. Report a backward timestamp instead of treating it as forward.
Reordered session marker. Reject the marker when its timestamp moves backward.
Native session start. Report it exactly once on the platform signal.
Explicit reset. Clear observation state without claiming that the market began a new session.

Put restart behavior in the contract

A pure classifier is only the start. If the bot carries a daily loss lock, trade counter or opening range across bars, choose the recovery model before implementation:

restore the last trusted state from persistent storage;
rebuild it from authorized account and chart history;
stay locked until the next verified native session boundary;
require an explicit operator decision in a demo or test environment.

Leaving this undefined is what creates restart-only bugs.

Keep the evidence packet small

For each run I record:

source hash and platform version;
instrument, bar type and trading-hours template;
ordered timestamps and native session markers;
expected and observed class for each test;
reload and restart result;
what was not tested.

That is enough to separate a code defect from a chart-template mismatch. It also keeps a later test from quietly using different source or settings.

The business rule should still fit in one sentence:

Reset named state when observable event occurs, provided state condition; otherwise keep the prior state until fallback event.

Then add one case where the reset must happen and one where it must not.

For the longer reasoning behind calendar midnight and native session events, see A Trading Session Is an Event, Not Just a Date.

This is about software behavior and testing. It is not investment advice and does not promise profitability or trading performance.

DEV Community: Arnold Holm

Eight Session-Boundary Tests I Run Before Trusting a Trading Bot

A small classifier first

The eight tests

Put restart behavior in the contract

Keep the evidence packet small