Lost response or rejected request?
Imagine paying for a meal but never seeing the confirmation page. Would you immediately pay again? A missing response from a trading system likewise does not establish rejection; repetition can duplicate exposure. This lesson concerns isolated demo controls. We do not alter live accounts or positions belonging to another program. The objective is to specify behavior under uncertainty, not experiment dangerously with customer funds or assume that communication will always remain reliable.
Missing response ≠ rejected order
A running server is not enough
A virtual server reduces dependence on a laptop; it cannot guarantee logic, data or execution. Record the latest valid quote time, connection, build and configuration. Distinguish system, broker and timezone references. The server was running does not explain an order; a decision log does. Stale data and invalid communication need predefined handling. Incomplete input must not be treated as valid simply because the process is alive and a dashboard looks healthy.
Version • settings • quote age • connection
An intent needs an identity
Give every submission intent a durable identity to recognize repeated events. Separate pending response, open exposure, unknown result and halted state. On restart, recover saved state and reconcile server orders. Clearing memory does not solve the risk; it destroys recovery evidence. Until the result is known, restrict new entries and repeated requests according to the safe policy. A successful function return is not always equivalent to a completed trade, so inspect the relevant server results and events.
Durable identity + recovery + reconciliation
Define what stopping means
Blocking entries differs from closing all positions. In our teaching model, entry is disabled while existing exposure follows a separate management policy. Forced closure has its own costs and risks. Do not touch unrelated positions. During disconnection, a local switch cannot guarantee delivery of an instruction to the broker. A server-side stop cannot guarantee an exact fill either. A button name is insufficient: behavior, scope and restart conditions must be explicit and testable.
Entry halt ≠ close everything Define the scope of control
Four failures to rehearse
Rehearse stale quotes, duplicate events, communication loss after submission and restart with open exposure. Write expected behavior first. Reject entry on stale data and reconcile unknown results before retrying. Numerical thresholds belong to the actual system specification; do not treat a teaching number as suitable for every instrument. The test should be repeatable and isolated so it cannot affect unrelated programs or exposure beyond the declared control scope.
Stale data • duplication • ambiguity • recovery
Evidence of a passed test
Retain the build, input, expectation, actual result and error. Printing success is insufficient; inspect order counts and state transitions. Simulation tests logic, not live execution quality. Logged demo observation is still needed. Several profitable days cannot replace reconnection and recovery drills. Each risk needs appropriate evidence. Every test should clearly state what it established and what remains unknown, rather than turning one successful check into a claim of complete safety.
Input → expected → actual Count orders and inspect state
Safety assignment
Complete the four-failure table with pass and fail conditions. Why not immediately repeat a request after losing the response? The original may already be accepted. Reconcile first, then decide. For restart, specify what must be recovered from storage and the server. Next we convert these controls into an evidence checklist for evaluating an EA before purchase. Reducing ambiguity is the goal; removing every operational and market risk is not a promise this lesson can make.
Reconcile first; then decide
