Engineering note · Manual intervention
Your MT5 EA Reopens a Manually Closed Trade. What Should It Do Instead?
You close an EA-managed position by hand. A moment later, the EA opens another one. The entry condition may still be true, while your intended instruction was to stop. A useful repair starts by defining what the manual action means, not by adding an arbitrary delay.
- 01Identify the exit
- 02Apply the agreed policy
- 03Retain the state
- 04Require a defined rearm event
Write down what closing by hand means
Manual close is an action, but it is not a complete strategy instruction. You might want to skip the current signal, pause the symbol until the next session, or stop new entries until explicitly resumed. Those are different behaviors. None should be guessed from a button click.
For example, a buyer could choose this rule: after a full manual exit from a managed position, block new entries for that strategy and symbol until the entry condition has first become false and then produced a fresh qualifying event. This is one possible contract, not a universal trading rule.
Make the scope explicit. Does the pause apply to one position, one direction, one strategy, one symbol or the entire account? Does it affect new entries only, or also management of remaining exposure? A global pause hidden inside a small repair can change unrelated behavior.
Identify the actual deal before changing state
MQL5 exposes deal properties for entry or exit classification, position identity and execution reason. Desktop, mobile and web origins have distinct reason values; expert, stop-loss and take-profit reasons are also separate. These fields help classify an event, but the reason alone is not the complete business rule.
Match the event to the position or cycle the EA actually manages. Retain the link from the managed entry to later deals. Do not assume that an exit has the same origin as the entry, or that every event on the symbol belongs to this EA.
A partial close needs its own branch. Decide whether the remaining volume keeps its existing management, whether further entries are blocked and how protection is reviewed. A reduction in volume is not the same state as a fully closed position. Reversals and unrelated account operations should not accidentally trigger the same rule.
- Identity: account alias, strategy, symbol and managed position or cycle.
- Observed event: deal identifier, time, entry classification and reason.
- Resulting exposure: remaining managed position and relevant pending orders.
- Policy result: continue, pause or wait for the named rearm condition.
Do not tie the rule to one callback sequence
The OnTradeTransaction reference says transaction arrival priority is not guaranteed and the account can change while the handler runs. Build the decision from the relevant deal evidence and reconciled state, rather than assuming one fixed sequence of callbacks.
Keep event handling bounded. Record the identity needed for review and avoid repeatedly applying the same transition when the same evidence is processed again. If history or the current position cannot be established, represent that uncertainty explicitly instead of treating it as permission to open again.
Also inspect pending orders under the agreed scope. Blocking a new market-entry path does not answer what should happen to a previously placed pending entry. The specification must say whether it remains, is cancelled or requires a separate decision. Record its actual outcome.
Make the pause survive the cases that matter
A pause that exists only in a temporary variable may disappear after a restart. Decide whether it must survive a terminal restart, chart reattachment and a settings change. Store or reconstruct the required state under an explicit identity and version policy.
Rearming needs observable evidence too. If the policy requires a false condition followed by a new signal, a condition that remains true throughout the interruption is not a fresh signal. Define how a restart with incomplete intervening data is handled. Do not invent the missing transition.
A good repair brief contains the original source, one redacted sequence showing the exit and unwanted re-entry, the chosen intervention policy and the checks below. A developer can then prove the bounded behavior. Passing those checks would not establish profitability or eliminate market execution risk.
Three acceptance checks
Proposed tests, not executed customer results. Record actual outcomes separately.
Full manual exit, condition still true
Input: Close the managed position in a demo test while its original entry condition remains true.
Expected: Under the example policy, no new entry is submitted. The trace identifies the exit and records the paused strategy and symbol.
Partial close and unrelated exit
Input: Reduce the managed position, then separately close an unrelated position.
Expected: Each follows its own agreed branch. Remaining exposure stays accounted for, and the unrelated exit does not silently pause or rearm this strategy.
Restart and fresh signal
Input: Restart while paused, then supply the defined false-to-new-signal sequence in the test environment.
Expected: The pause is retained or safely reconstructed. Entry becomes eligible only after the named rearm evidence; incomplete history does not manufacture permission.