DEV Community: Arnold Holm

A Missing Risk Check Is Not a "No"

Arnold Holm — Wed, 23 Sep 2026 07:26:50 +0000

A decision trace says WAIT. Did the risk check actually return false, or did its service time out?

Both paths may submit no order, but they need different fixes. An observed rejection means inspect the rule and its inputs. A timeout means restore the source of evidence. If the trace calls both WAIT, the second problem can sit there unnoticed.

My earlier example kept false separate from an absent field. Raju's follow-up question points to the next boundary: an observation can be present in the record but unavailable or invalid. The decision itself must respect that status.

Give each input an evidence state

This small example has two required checks: routeConnected and riskAllowed. It is a decision-trace example, not an order executor.

Recorded input	Meaning	Decision state
`observed`, `value: true`	The check ran and passed	Continue to the other checks
`observed`, `value: false`	The check ran and failed	`WAIT`, if all required observations are valid
`unavailable`, with reason and attempt ID	The source did not provide a result	`BLOCKED`
`invalid`, with reason and source ID	A result arrived but failed validation	`BLOCKED`
No input record	The trace is incomplete	`BLOCKED`

The important order is: inspect all required inputs for missing or unusable evidence, then evaluate the observed booleans. Otherwise an early false can hide a later timeout.

A small decision boundary

const gateNames = ['routeConnected', 'riskAllowed'];

function decide(trace) {
  if (!trace || typeof trace.decisionId !== 'string' || !trace.decisionId) {
    return { state: 'BLOCKED', reason: 'missing_decision_id' };
  }

  const inspected = [];
  for (const gate of gateNames) {
    if (!trace.observations || !Object.hasOwn(trace.observations, gate)) {
      return { state: 'BLOCKED', gate, reason: 'missing_observation' };
    }

    const observation = trace.observations[gate];
    if (!observation || typeof observation !== 'object') {
      return { state: 'BLOCKED', gate, reason: 'invalid_envelope' };
    }

    if (observation.status === 'observed') {
      if (typeof observation.value !== 'boolean' || !observation.sourceEventId) {
        return { state: 'BLOCKED', gate, reason: 'invalid_observed_value' };
      }
      inspected.push({ gate, value: observation.value, evidenceId: observation.sourceEventId });
      continue;
    }

    if (observation.status === 'unavailable' || observation.status === 'invalid') {
      if (!observation.reason || !observation.evidenceId) {
        return { state: 'BLOCKED', gate, reason: 'missing_failure_evidence' };
      }
      return {
        state: 'BLOCKED', gate,
        reason: `${observation.status}:${observation.reason}`,
        evidenceId: observation.evidenceId
      };
    }

    return { state: 'BLOCKED', gate, reason: 'unknown_status' };
  }

  const failed = inspected.find(observation => observation.value === false);
  if (failed) {
    return { state: 'WAIT', gate: failed.gate, reason: 'observed_false', evidenceId: failed.evidenceId };
  }
  return { state: 'READY', reason: 'all_observed_true' };
}

For example, riskAllowed: { status: 'unavailable', reason: 'risk_service_timeout', evidenceId: 'poll-21' } produces BLOCKED. The poll-21 reference names the failed attempt. It does not pretend there was a risk observation. By contrast, { status: 'observed', value: false, sourceEventId: 'risk-20' } produces WAIT and points to the actual result.

Tests that make the distinction visible

I ran this boundary with Node's built-in test runner. All six local cases passed:

Two observed true inputs produce READY.
An observed false produces WAIT with its source event ID.
An unavailable risk service produces BLOCKED, never WAIT.
An invalid risk value produces BLOCKED with a reason.
A missing required observation produces BLOCKED.
A false route check cannot hide an unavailable risk check. The result remains BLOCKED.

The sixth case matters most. A system can decline to place an order in both cases while still telling its operator the wrong reason. The trace should preserve whether it saw a negative result or lacked evidence to decide.

This example only tests the decision mapping. It does not prove that a source event ID exists, that an observation is fresh, or that a broker accepted or filled anything. A production trace should retain observation time and source identity, reject stale records, and join the decision to any later order request and fill as separate events.

To check your own boundary, remove one required input, replace another with false, then make its source unavailable. If all three cases show the same state and reason, the trace still loses a failure mode.

Reference: Node.js test runner.

A Successful Response Can Still Belong to the Wrong Screen

Arnold Holm — Sun, 20 Sep 2026 18:23:33 +0000

A trading dashboard requests an instrument preview. Before the response arrives, the user selects another instrument. Both requests succeed. The older one finishes last and replaces the newer view.

Nothing failed at the transport layer. The bug is accepting a result that no longer belongs to the current selection.

This article uses a small synthetic JavaScript fixture. It is a UI acceptance example, not a broker integration or an order-routing system.

Give each selection its own identity

Comparing only the instrument name is insufficient. Consider ES, then NQ, then ES again. A response from the first ES request must not become valid merely because the screen says ES again.

For one in-memory JavaScript session, a fresh object can serve as the request ticket:

function session() {
  let current = null;
  let view = null;
  return {
    select(instrument) {
      current = { instrument };
      view = null;
      return current;
    },
    accept(ticket, result) {
      if (ticket !== current) return false;
      view = { instrument: ticket.instrument, result };
      return true;
    },
    read: () => view,
  };
}

The ticket is created when the selection changes, captured by the request, and checked immediately before committing the result. The server does not need to know this local object.

const s = session();
const first = s.select('ES');
s.select('NQ');
const latest = s.select('ES');

console.assert(s.accept(first, 'stale') === false);
console.assert(s.read() === null);
console.assert(s.accept(latest, 'fresh') === true);

No timer or live service is required to exercise the failure. Deliver responses in the wrong order on purpose. That makes the acceptance rule reproducible instead of hoping a slow network reveals it.

Four checks, including the same-symbol case

Sequence	Expected result
Select ES, complete its current request	ES result appears
Select ES then NQ, complete NQ then ES	NQ remains visible
Select ES, NQ, ES; complete the first ES request	Old result is rejected
Display ES, then select NQ before completion	Old result is cleared

I ran these four cases with Node's built-in test runner. All four passed. They test this small in-memory acceptance function only.

Cancellation and acceptance do different jobs

Cancelling obsolete work can save resources. A separate acceptance check answers whether a completion may change the current view. Apply the same ownership check to success, error and loading-state updates; an old error should not replace a newer successful result either.

Object identity is deliberately local. A process boundary, persisted request or reload needs an explicit request identifier and a defined lifetime. This fixture also does not validate the payload, prove data freshness, handle authorization or prevent duplicate broker actions.

What to put in a repair brief

“The wrong symbol sometimes appears” is difficult to reproduce. Specify the selection sequence, completion order and exact view expected after each completion. Include the switch-away-and-back case. That one distinguishes selection identity from a coincidentally matching symbol name.

The useful boundary is simple: a successful response is allowed to update the screen only while its request still owns that screen state.

A Decision Trace Must Distinguish False From Missing

Arnold Holm — Thu, 17 Sep 2026 14:53:19 +0000

A dashboard says WAIT. Was the spread check false, or did the engine never receive a spread observation?

Those are different failures to investigate. A trace that turns both into an empty cell loses the distinction before debugging starts.

A current discussion about trading-engine decision traces asks which evidence belongs beside a score and decision. My answer starts with a small requirement: preserve the inputs that actually existed at decision time, including explicit false values.

Give missing data its own meaning

For this example, the input contract has two boolean observations: sessionOpen and spreadAllowed. It is deliberately narrower than a real engine.

false means the check ran and the condition was not met.
A missing key means the observation was not recorded.
null is invalid for this particular contract. A system that permits unavailable observations should give them an explicit status and reason.

Do not validate a boolean with if (!value). That rejects a perfectly legitimate false result. Check presence and type separately.

A runnable boundary test

Save the following as trace.test.mjs and run node --test trace.test.mjs. It uses Node's built-in test runner, with no packages or broker connection.

import test from 'node:test';
import assert from 'node:assert/strict';

function requireSnapshot(trace) {
  for (const key of ['decisionId', 'sourceEventId', 'codeVersion', 'configVersion']) {
    if (typeof trace[key] !== 'string' || trace[key].trim() === '') {
      throw new Error('Missing ' + key);
    }
  }
  if (!trace.features || typeof trace.features !== 'object') {
    throw new Error('Missing features');
  }
  for (const key of ['sessionOpen', 'spreadAllowed']) {
    if (!Object.hasOwn(trace.features, key) || typeof trace.features[key] !== 'boolean') {
      throw new Error('Invalid feature ' + key);
    }
  }
  return trace;
}

const fixture = () => ({
  decisionId: 'decision-example', sourceEventId: 'event-example',
  codeVersion: 'example-build', configVersion: 'example-config',
  features: { sessionOpen: true, spreadAllowed: false }
});

test('false is recorded evidence, not missing data', () => {
  const trace = fixture();
  assert.equal(requireSnapshot(trace), trace);
});
test('an omitted feature is rejected', () => {
  const trace = fixture();
  delete trace.features.spreadAllowed;
  assert.throws(() => requireSnapshot(trace), /Invalid feature spreadAllowed/);
});
test('null is not a boolean observation', () => {
  const trace = fixture();
  trace.features.spreadAllowed = null;
  assert.throws(() => requireSnapshot(trace), /Invalid feature spreadAllowed/);
});
test('a missing configuration version is rejected', () => {
  const trace = fixture();
  trace.configVersion = '';
  assert.throws(() => requireSnapshot(trace), /Missing configVersion/);
});

The four tests passed locally. That result covers this small validation function only. It does not establish the correctness of a trading strategy, broker integration or production trace pipeline.

What the version fields do, and do not do

The example also requires non-empty code and configuration version strings. An absent configuration identifier makes it hard to explain why the same event behaved differently after an input change.

But a string is only a reference. This validator does not prove that the referenced build exists, that its contents match the identifier, or that the configuration was the one actually running. Production evidence needs those links to be checked and retained.

I would store the input snapshot when the decision is made. Rebuilding it later from the latest chart or a revised data feed can silently describe a different decision.

Keep the decision separate from its consequences too. A BUY decision, a submitted order request and an observed fill are three different facts. Join their records with identifiers; do not overwrite one status field until the earlier facts disappear.

Try the failure path

Start with one saved test trace. Remove a required feature and confirm the reader rejects it. Restore the feature as false and confirm it survives unchanged. Then change the configuration reference and check that your investigation tools display the different version.

This is a narrow test of evidence quality. A populated table is useful only if the values still mean what the engine meant when it wrote them.

Reference: Node.js test runner.

A Trading Restriction Needs an Owner: Three Tests for Account Scope

Arnold Holm — Wed, 16 Sep 2026 18:37:33 +0000

You move an instrument between two accounts. A restriction created for the source account follows the instrument into the destination account. The code finds the right symbol, returns a valid boolean, and still makes the wrong decision.

I would test that ownership boundary before adding another trading rule. A correct symbol match does not establish which account a restriction belongs to.

This post builds a small, copyable JavaScript test for that boundary. It does not connect to a broker, place an order, or reproduce a full trading system. Its claim is narrower: an account-specific restriction must not become a global restriction just because another account holds the same symbol.

Start with the decision, not the database column

The prompt for this example was finaltype's public account-scope write-up. That discussion describes an exclusion applying beyond its intended account. The example below is independent; it is not a patch to that author's application.

Imagine three accounts: source, destination, and unrelated. All three may hold the instrument represented by the invented symbol DEMO.

A user creates a do-not-rebuy flag for source. The first question is not whether a row for DEMO exists. It is whether that row applies to the account making the current decision.

I would write the ownership rule like this:

flag for DEMO
    |
    +-- account scope: source
    |       +-- source      -> applies
    |       +-- destination -> does not apply
    |       +-- unrelated   -> does not apply
    |
    +-- explicit global scope
    |       +-- every account holding DEMO -> applies
    |
    +-- missing scope -> unresolved input, not a global default

That is the technical boundary. What an applicable flag actually does is a separate decision. Blocking a future purchase and requesting a sale are not interchangeable actions. This example deliberately produces neither.

Make the three acceptance cases visible

Before the implementation, name the observations that would disprove it.

Case	Setup	Required observation
Account isolation	Restriction belongs to `source`	It applies there, but not to `destination` or `unrelated`
Explicit global scope	Restriction is deliberately global	It applies across accounts for the matching symbol, but not another symbol
Missing ownership	A matching record has no scope, or an account flag has no account ID	Evaluation reports unresolved scope rather than treating it as global

The unrelated account matters. A test with only the source and destination can become tightly coupled to a particular transfer workflow. A third account checks the broader rule: sharing a symbol is not permission to share an account-specific decision.

The different-symbol assertion matters too. A global restriction in this example is global across accounts, not across every instrument. Those are different meanings of the word global, and a test should force the distinction.

Copy the complete fixture

Save the following as scope.test.mjs. It uses Node's built-in test runner and strict assertions, without dependencies or a broker connection.

import test from 'node:test';
import assert from 'node:assert/strict';

function applies(flag, accountId, symbol) {
  if (flag.symbol !== symbol) return false;
  if (flag.scope === 'global') return true;
  if (flag.scope !== 'account' || !flag.accountId) {
    throw new Error('Unresolved flag scope');
  }
  return flag.accountId === accountId;
}

const sourceFlag = {
  symbol: 'DEMO', scope: 'account', accountId: 'source'
};

test('account restriction stays inside its account', () => {
  assert.equal(applies(sourceFlag, 'source', 'DEMO'), true);
  assert.equal(applies(sourceFlag, 'destination', 'DEMO'), false);
  assert.equal(applies(sourceFlag, 'unrelated', 'DEMO'), false);
  assert.equal(applies(sourceFlag, 'source', 'OTHER'), false);
});

test('explicit global scope applies to the matching symbol', () => {
  const globalFlag = { symbol: 'DEMO', scope: 'global' };
  assert.equal(applies(globalFlag, 'source', 'DEMO'), true);
  assert.equal(applies(globalFlag, 'destination', 'DEMO'), true);
  assert.equal(applies(globalFlag, 'source', 'OTHER'), false);
});

test('missing scope does not silently become global', () => {
  assert.throws(() => applies({ symbol: 'DEMO' }, 'source', 'DEMO'),
    /Unresolved flag scope/);
  assert.throws(() => applies({ symbol: 'DEMO', scope: 'account' },
    'source', 'DEMO'), /Unresolved flag scope/);
});

Run it with:

node --test scope.test.mjs

The expected result is three passing tests. The Node test runner documentation explains the command and the node:test module.

For a useful negative control, replace the function body temporarily with return flag.symbol === symbol. The account-isolation case and missing-scope case should fail. If your actual regression suite stays green after removing the ownership check, it is not protecting this boundary.

Missing scope is a migration decision

The example refuses to interpret an old, unscoped record as global. That is a design choice for this fixture, not a universal migration instruction.

An existing product might have promised that every legacy restriction was global. If so, preserving that contract may be correct. Write the migration rule explicitly, label the converted records, and test the intended behavior before replacing the reader.

What I would avoid is letting missing data make that decision accidentally. A nullable column, an empty string, and an explicit global value should not quietly acquire the same meaning without a written rule.

Also keep migration separate from evaluation. A migration can decide how an old record becomes a valid new record. The evaluator can then deal with a much smaller set of supported states. That separation makes the review easier: one change transforms stored meaning; another applies the agreed meaning.

A boolean is only one layer

Passing these tests does not prove that a trading application is safe to run. The fixture assumes validated account and instrument identifiers. It does not resolve broker symbol aliases, verify user permissions, read a database, or test concurrent updates.

In an application, the caller must handle unresolved scope as an explicit error state. Catching the exception and continuing as though no restriction exists would defeat the purpose. A visible hold with a diagnostic reason is one possible policy; the product needs to choose and test its own behavior.

The storage path also needs coverage. If a query discards the account field before this function runs, the function cannot recover the lost information. Test the actual stored record, the query result, and the final decision together in an integration test.

Finally, do not combine this check with broker-balance reconciliation. A restriction leaking across accounts and a ledger disagreeing with broker holdings are separate failures. Give each its own input, expected result, and evidence. Otherwise one passing assertion can hide which behavior was never exercised.

The next useful step is small: find one account-scoped flag in your application, identify the writer and every reader, and add a test using the same symbol in an unrelated account. Keep the expected result beside the test. That makes ownership reviewable before the flag reaches an order-producing path.

Wrong Target, Clean Success: A Node Test for Misrouted Saves

Arnold Holm — Wed, 09 Sep 2026 12:20:42 +0000

A dated defect worth learning from

On 23 August 2026, issue 475 in tradingview-mcp reported that pine_new and pine_open changed editor content without changing the saved script bound to it. A later save could therefore write to the wrong script. The report cites TradingView Desktop 3.3.0.7992 and Node 24.15.0. Its pine_new observation stopped before a successful save, and the destructive pine_open sequence was inferred from source rather than run to completion. This is dated motivation for a synthetic test, not a claim about today's software.

The pattern

The pattern is simple. A caller intends one record. The store has a different record active. A save follows the active binding instead of the intent. The response reports success. The intended record never changes. The active record loses its original text. Nobody gets a signal, because every message on the happy path looks correct until someone opens the wrong file.

Two identities sit behind every save like this. The intended identity is the record the caller means to write. The active identity is the record the store currently has open. When the two differ, the write should stop before it starts. That is the whole idea, and the rest of this article is one small way to test it.

Why the success message makes it worse

The report raises another useful point: opening a script sounds like inspection. A caller may not expect it to alter an existing buffer. Yet a successful response can hide that distinction. The report also suggested a cheap remedy in the same spirit: have the save return the name and id of the script it actually wrote. A caller that sees the wrong name come back notices immediately. The check in this article moves that idea to the caller side, before the write instead of after it.

The toy model

The demonstration is synthetic and narrow on purpose. It models two saved scripts, A and B, as full records in a Map. Each record carries an id, a name, and source text. A naive save writes new source into whatever record is active, which is how the defect lives. A guarded save takes an intended id and an active id, validates both, and writes only when they match.

I keep the checks strict in a specific way. Each case snapshots the full records with structuredClone before the operation, then compares the complete Map with assert.deepEqual after each rejected write (structuredClone is available in Node 17 and later). Checking one field would leave the rest of a record unverified, and a wrong claim could pass. After every rejected operation the test compares the complete Map against its snapshot, one rejection at a time. This also catches an unexpected added or deleted entry. The correct-target case checks the whole untouched B record the same way, so the untouched side is verified as a record, not as one field.

Standalone test program

The program below is one file and depends only on node:assert/strict. Save it as check.mjs and run it with Node.

import assert from 'node:assert/strict';

function makeStore() {
  return new Map([
    ['A', { id: 'A', name: 'Script A', source: 'source A v1' }],
    ['B', { id: 'B', name: 'Script B', source: 'source B v1' }],
  ]);
}

// Full-record snapshot, so comparisons cover every field.
function snapshot(store) {
  const out = new Map();
  for (const [key, record] of store) out.set(key, structuredClone(record));
  return out;
}

function naiveSave(store, activeId, newSource) {
  const record = store.get(activeId);
  if (!record) throw new Error('missing id');
  record.source = newSource;
  return activeId;
}

function guardedSave(store, intendedId, activeId, newSource) {
  if (typeof intendedId !== 'string' || intendedId.length === 0) {
    throw new Error('invalid intended id');
  }
  if (typeof activeId !== 'string' || activeId.length === 0) {
    throw new Error('invalid active id');
  }
  if (intendedId !== activeId) throw new Error('wrong target');
  const record = store.get(intendedId);
  if (!record) throw new Error('missing id');
  record.source = newSource;
  return intendedId;
}

// Case 1: naive misroute, the defect demonstrated.
{
  const store = makeStore();
  const before = snapshot(store);
  assert.notEqual('A', 'B');
  const out = naiveSave(store, 'B', 'source A v2');
  assert.equal(out, 'B');
  assert.deepEqual(store.get('A'), before.get('A'));
  assert.deepEqual(store.get('B'), { id: 'B', name: 'Script B', source: 'source A v2' });
  console.log('case 1 naive misroute: B holds A v2, A record unchanged');
}

// Case 2: mismatch rejected, both full records unchanged.
{
  const store = makeStore();
  const before = snapshot(store);
  assert.throws(() => guardedSave(store, 'A', 'B', 'source A v2'), /wrong target/);
  assert.deepEqual(store, before);
  console.log('case 2 guarded mismatch: rejected, both records unchanged');
}

// Case 3: correct target, A updated, whole B record untouched.
{
  const store = makeStore();
  const before = snapshot(store);
  const out = guardedSave(store, 'A', 'A', 'source A v2');
  assert.equal(out, 'A');
  assert.deepEqual(store.get('A'), { id: 'A', name: 'Script A', source: 'source A v2' });
  assert.deepEqual(store.get('B'), before.get('B'));
  console.log('case 3 correct target: A updated, B record unchanged');
}

// Case 4: invalid and missing identities, checked after every rejection.
{
  const store = makeStore();
  const before = snapshot(store);
  assert.throws(() => guardedSave(store, '', 'A', 'x'), /invalid intended id/);
  assert.deepEqual(store, before);
  assert.throws(() => guardedSave(store, 'A', '', 'x'), /invalid active id/);
  assert.deepEqual(store, before);
  assert.throws(() => guardedSave(store, 'Z', 'Z', 'x'), /missing id/);
  assert.deepEqual(store, before);
  console.log('case 4 invalid ids: three rejections, no writes');
}

What each case checks

Case 1 keeps the naive misroute on display. The intended record is A, the active record is B, and the naive save writes A's new text into B. The test asserts B now holds A's text while A keeps its original full record, which is the defect stated as a fact.

Case 2 sends the same mismatch through the guarded save. The guard throws wrong target, and the test compares both full records against their snapshots. Nothing was written.

Case 3 matches intended and active on A. The guard writes, A's full record shows the new source, and the whole B record stays equal to its snapshot.

Case 4 feeds three bad identities: an empty intended id, an empty active id, and a missing id Z. Every rejection is followed by a full-record comparison, so a partial write cannot hide between attempts.

Each case group prints one line after its assertions pass. An assertion failure stops the program before that line. The run record below contains the observed output.

Test table

The table states the contract the asserts enforce. Expected mutation means what the store should look like after the operation.

Scenario	Input	Expected mutation
Naive misroute	intended A, active B, naive save with A v2 source	B record rewritten to hold A v2; A record unchanged; B v1 text gone
Guarded mismatch	intended A, active B, guarded save	no mutation; both full records equal their snapshots; wrong target error
Correct target	intended A, active A, guarded save	A record updated to v2 source; whole B record unchanged
Invalid intended id	intended empty string, active A	no mutation; both full records equal snapshots; invalid id error
Invalid active id	intended A, active empty string	no mutation; both full records equal snapshots; invalid id error
Missing record	intended Z, active Z	no mutation; both full records equal snapshots; missing id error

Run status

I ran the exact listing with node check.mjs on Node v23.6.1 on 9 September 2026. The process exited with code 0 and printed:

case 1 naive misroute: B holds A v2, A record unchanged
case 2 guarded mismatch: rejected, both records unchanged
case 3 correct target: A updated, B record unchanged
case 4 invalid ids: three rejections, no writes

Where this check stops

The model is synchronous, single-threaded, and in memory. It shows the guard catching a mismatch inside one toy store, and nothing beyond that. It is not evidence about async flows, races between operations, atomicity of a check plus a write, persistence, or concurrent writers. It is not a real editor test. No TradingView component, MCP server, or Monaco editor is involved anywhere in the listing.

The gap matters. An explicit intended-id guard in a synchronous model is not sufficient for async persistence. Between the check and the write, the active binding can change, or a second writer can commit first. The comparison has to happen at the single point where the store persists, as an atomic conditional write or a version check that accepts or rejects the whole operation together. That is where a real fix belongs. This article names that place and does not claim any implementation of it.

Reuse it

The useful part is the shape of the test. Snapshot whole records before the operation. Reject on identity mismatch before any write. Compare full records after every rejection, one rejection at a time. Keep the naive path in case 1 so the failure stays visible next to the fix. Then change names, fields, and store to match your own system. A toy that runs in seconds and states its own limits is easier to trust than a promise that never shows its checks.

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.