Treat a restart as a normal input to the system
An Expert Advisor can look stable in a backtest and still behave badly after the terminal restarts, the EA is recompiled, the chart timeframe changes, or its inputs are edited. MQL5 generates initialization and deinitialization events around these lifecycle changes. The official OnInit documentation describes initialization immediately after an EA is loaded, while OnDeinit receives a reason code for events such as removal, recompilation and chart changes [1, 2]. A production-minded EA therefore needs a defined recovery path instead of assuming its in-memory variables have always existed.
The core engineering question is simple: if every local variable is reset to its default value but the trading account still contains positions or pending orders created by this strategy, can the EA reconstruct enough state to continue without duplicating actions? This is a software-reliability question, not a claim about profitability.
Rebuild broker-side state before allowing new entries
At startup, enumerate the account state that can affect the strategy before enabling fresh order generation. MQL5 exposes open positions through PositionsTotal and PositionGetTicket, and current pending orders through OrdersTotal and OrderGetTicket [3, 4, 5, 6]. Do not merge those concepts: an order is a request, while a position is the result of one or more deals. The distinction matters because a restart may occur while a pending order exists even though no position has been opened yet.
Filter the account objects using the identifiers your design actually owns, such as symbol and Magic Number, rather than treating every account position as strategy state. Also account for the position model. MetaQuotes documents that netting accounts allow one position per symbol, while hedging accounts can hold multiple positions on the same symbol [3]. Recovery logic that was tested only on one model can make incorrect assumptions on the other.
Prefer durable identifiers over fragile local flags
A local flag named something like has_position can disappear on restart, so it should not be the final authority. Position properties provide broker-side identifiers that can be read again. MetaQuotes documents POSITION_MAGIC for the position's Magic Number and POSITION_IDENTIFIER as an identifier that remains associated with the position life cycle, while POSITION_TICKET can change in some server-side service operations [7]. That makes the exact choice of key an engineering decision worth documenting.
A practical recovery record might say: this EA owns positions whose symbol matches the configured symbol and whose Magic Number matches the strategy instance; when deeper reconciliation is needed, position identifiers and related order or deal history are recorded. HistorySelect can load orders and deals for a specified server-time interval, which lets a recovery routine investigate what happened before the restart instead of inventing a story from the current snapshot alone [8].
Persist only what cannot be reconstructed, and label its limits
MQL5 also provides client-terminal global variables. They are shared among MQL5 programs in the terminal and, according to the official reference, normally remain for four weeks since their last access. Temporary global variables disappear when the terminal shuts down [9, 10]. These facilities can be useful for lightweight checkpoints such as a last processed identifier, but they are not a substitute for reconciling the actual account.
If you use terminal globals, namespace the names so different EAs do not collide, and treat the stored value as a hint that must be checked against current broker-side state. A stale checkpoint can survive while an order was filled, canceled or modified elsewhere. Conversely, a temporary variable can vanish exactly when a restart test is trying to prove persistence. The acceptance test should therefore distinguish authoritative account state from optional local convenience state.
Worked example: prevent the duplicate entry after restart
Consider a hypothetical demo scenario. Before shutdown, one pending order belonging to the EA is active and the in-memory variable entry_pending is true. The terminal restarts, so entry_pending returns to its default false value. A fragile EA sees false, evaluates the same signal again and submits a second pending order. A restart-safe EA first enumerates current orders, finds the existing order that matches its ownership rules, rebuilds the internal state and blocks the duplicate path.
Now change the scenario: the pending order was filled while the EA was unavailable, so an open position exists when OnInit runs. The recovery path should discover that position before deciding whether a new entry is allowed. If the strategy also needs to know how that position appeared, it can query history for the relevant interval and reconcile identifiers. The exact business rule is strategy-specific; the test objective is not. The same external account state must produce the same safe internal decision regardless of whether the EA has just restarted.
Run a restart matrix, not one happy-path test
Build an acceptance matrix in the Strategy Tester where feasible, or in a controlled demo environment for lifecycle behavior that requires a terminal restart. Cover at least these states: no exposure; one owned pending order; one owned open position; unrelated manual or other-EA exposure; and, if your account type supports it, multiple hedged positions. For each case record the objects discovered at initialization, the reconstructed state, and whether new order generation was enabled or blocked.
Add one failure case in which a required dependency cannot be reconstructed. OnInit can return a failure code and unload the EA when initialization cannot safely continue [1]. That is often better than silently guessing. The references for this article were rechecked on 26 September 2026. Broker behavior, account type, server history availability and strategy ownership rules remain external limitations. Continue with BamaUp's free Auto-Trading Foundations path and EA validation checklist. Testing a restart path can expose software faults; it cannot guarantee future trading results.
