DEV Community

Arnold Holm
Arnold Holm

Posted on

Trace a Missed MT5 Entry Without Turning Missing Data into a False Signal

#javascript #testing

A buyer describes an EA that sometimes misses an entry visible on the chart. The request also says to preserve the existing strategy. Those two requirements belong together: forcing an entry by removing a filter is not a repair if that filter was supposed to block it.

The public request asks about candle indexing, timing and hidden entry filters. Here is a small implementation question behind that symptom: does the diagnostic distinguish an unavailable input from a genuine false signal?

Give each stage a separate outcome

An entry trace should retain the full symbol, timeframe, bar timestamp, evaluation timestamp and source revision. Then record the inputs actually read and the first decision that prevents progress.

Avoid a single boolean named canTrade. It can merge several different outcomes:

  • A required indicator value was unavailable.
  • The written signal did not qualify.
  • The signal qualified, but an existing gate blocked it.
  • The signal was eligible for a request.

Only the last outcome reaches the request boundary. It still does not mean a broker accepted an order or a position exists.

A tiny classifier you can run

This JavaScript fixture models the diagnostic states only. It is not an MT5 EA, does not reconstruct candles and sends no request.

import assert from 'node:assert/strict';

function classifyEntry(o) {
  if (!o.dataReady) return { stage: 'input', reason: 'unavailable' };
  if (!o.signal) return { stage: 'signal', reason: 'not-qualified' };
  if (o.blocker) return { stage: 'gate', reason: o.blocker };
  return { stage: 'request', reason: 'eligible-not-yet-submitted' };
}

assert.deepEqual(
  classifyEntry({ dataReady: true, signal: true, blocker: null }),
  { stage: 'request', reason: 'eligible-not-yet-submitted' }
);
assert.deepEqual(
  classifyEntry({ dataReady: true, signal: true, blocker: 'outside-session' }),
  { stage: 'gate', reason: 'outside-session' }
);
assert.deepEqual(
  classifyEntry({ dataReady: false, signal: true, blocker: null }),
  { stage: 'input', reason: 'unavailable' }
);
console.log('Three classification checks passed. No order was submitted.');
Enter fullscreen mode Exit fullscreen mode

Save it as trace.mjs and run node trace.mjs. The owned companion fixture passed these three assertions. That result concerns classification precedence only, not the buyer's code or a terminal run.

The awkward case is the useful one

The last assertion deliberately supplies signal: true alongside unavailable data. The classifier refuses to use that signal. This could represent a stale value accidentally carried from a previous evaluation. In real source, data readiness needs its own implementation and evidence; this fixture only demonstrates the intended precedence.

Likewise, a qualifying signal with outside-session remains blocked. If a proposed fix makes it eligible, the negative control exposes a changed strategy rule.

Respect the event boundary

MQL5's OnTick reference says events are processed sequentially and another NewTick is not queued while one is queued or processing. It also separates OnTick processing from permission to send trades. A trace must not assume that every market tick became a distinct handler call, or that running calculations prove trading was enabled.

Freeze the bar timing before mapping this classifier into an EA. Record buffer availability, actual signal values and the named gate. After submission, append the request result and the observed order or position state as separate evidence.

The buyer-facing missed-entry guide covers the incident brief and acceptance boundary. Neither this fixture nor that guide claims to diagnose an unseen EA, prove a live sequence or predict trading performance.

Top comments (0)