A Paired Buy and Sell EA Needs One Explicit Cycle State

Arnold Holm — Wed, 02 Sep 2026 12:34:42 +0000

A paired buy and sell EA can open both legs correctly and still fail after the first exit. The reason is usually not the entry signal. The lifecycle was never defined.

That distinction matters to a buyer because a clean compile only proves that the code is syntactically valid. It does not prove that the Expert Advisor knows which cycle is active, which leg survived, or whether a restart permits another entry.

The buyer question

Before development starts, the specification should answer one question:

What state is the EA in after one leg closes, and what exact event completes the cycle?

If that answer is vague, the implementation can place a replacement order too early, leave an orphaned position unmanaged, or restart into the wrong state.

Use one explicit lifecycle

A practical model has four states:

IDLE: no active pair exists and a new cycle may start.
PAIR_OPEN: both legs belong to the active cycle.
ONE_LEG_CLOSED: one leg has exited and the remaining leg still belongs to the same cycle.
CYCLE_COMPLETE: both legs are closed, cleanup is complete, and the EA may return to IDLE.

The names can change. The important part is that every transition has one deterministic trigger.

For example, the transition from PAIR_OPEN to ONE_LEG_CLOSED should be caused by one verified close event for a ticket that belongs to the active cycle. It should not be inferred only from a temporary order count. The transition from ONE_LEG_CLOSED to CYCLE_COMPLETE should require proof that the survivor has closed and that no cycle-owned pending order remains.

A minimal transition table

Current state	Verified event	Next state	Forbidden side effect
IDLE	entry condition and no active cycle	PAIR_OPEN	opening two cycles
PAIR_OPEN	one cycle-owned leg closes	ONE_LEG_CLOSED	replacing the closed leg
ONE_LEG_CLOSED	survivor closes	CYCLE_COMPLETE	opening a new pair twice
CYCLE_COMPLETE	cleanup persisted	IDLE	losing the completed-cycle record

This table gives a buyer something more useful than “the bot works.” It defines what can be checked.

Freeze three acceptance tests

1. Normal closure

Both entries fill. Both legs close through their intended exit rules. The EA records the cycle as complete and does not open a replacement until the next valid cycle trigger.

The evidence should include the two entry tickets, both close events, the single cycle identifier, and the final state.

2. One leg closes first

One position hits its stop, target, or included manual-close condition. The surviving leg remains managed by the current cycle. The EA must not treat the account as flat and must not create a duplicate pair.

This is where many apparently simple paired-order requests become ambiguous. “Keep the other trade running” is not enough. The specification still needs to say which management rules remain active and whether another signal is ignored until the survivor closes.

3. Terminal restart

MetaTrader restarts while the pair is open or while one leg remains. The EA reconstructs the same state from durable identifiers and current positions. It must not depend only on variables that disappeared with the terminal session.

A useful restart test records the state before shutdown, starts the terminal again, and compares the reconstructed cycle identifier, leg ownership and permission to open the next pair. Any difference is a failed acceptance case.

The identifiers matter

A stable implementation should be able to answer:

Which positions belong to the current cycle?
Which leg is the buy and which is the sell?
Has either leg already closed?
Was the close expected, manual, or caused by a broker event?
Is a new cycle allowed now?

Magic numbers, symbols, comments, ticket mappings and persisted cycle identifiers can all help. The correct combination depends on the platform and scope. What matters is that the reconstruction rule is explicit and testable.

In MT4, order-history scans also need a fixed selection rule. “Take the last closed order” can be wrong when another EA or a manual trade uses the same account. In MT5 hedging mode, position and deal history introduce a different mapping problem. Platform choice is part of the acceptance contract, not a detail to leave until coding.

Warning signs in a specification

The following phrases usually need clarification before coding:

“Open a new pair when one trade closes.”
“Keep the other trade running as normal.”
“Restart the bot after both trades finish.”
“Avoid duplicate orders.”

Each phrase hides multiple state transitions. Does a partial close count? What happens after a manual close? What if the broker rejects one entry? What if the terminal restarts between the close event and the state update?

These are not reasons to delay the project. They are decisions that can be frozen as safe defaults. For a first version, a reasonable boundary might reject partial closes, keep the survivor under its original stop and target, and permit the next cycle only after both legs and all cycle-owned pending orders are gone.

Scope boundaries prevent revision loops

A clean first version should state which close paths are included. It should also list exclusions such as partial closes, cross-symbol baskets, manual intervention, broker-side order changes, or recovery from edited comments if those cases are not part of the initial scope.

That is not bureaucracy. It gives the buyer and developer the same definition of “done.” A revision is then about a failed agreed case, not a new interpretation of an undefined lifecycle.

What proof should be delivered?

For this kind of EA, a useful handover contains more than the .mq4 or .mq5 file:

editable source code;
a clean compile result;
the transition table used by the implementation;
logs or screenshots for the three acceptance cases;
a short change note;
setup notes covering platform mode, symbol and identifiers.

The source lets the buyer retain control. The matrix makes the behavior reviewable. The evidence separates “compiled” from “accepted.”

A simple pre-coding checklist

Before funding implementation, freeze:

the four lifecycle states;
every allowed transition;
the identifier used to rebuild state;
the three acceptance tests above;
the included close paths;
the excluded edge cases;
the exact event that allows the next cycle.

Once those points are deterministic, the entry and exit rules become much easier to implement and test.

The full buyer checklist is available here: https://stratcorealpha.com/engineering-notes/mt4-paired-order-lifecycle

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