· 4 min read
MT5 Order Timeout: Check Broker State Before Retrying a Trade
Distinguish an order timeout from an explicit rejection. Reconcile pending orders, positions, and deals, and understand how TickerAI reuses an idea reference on retries.
By TickerAI
An order timeout means the response did not arrive within the expected time. It does not necessarily mean the broker rejected the request or that no trade exists. Treat the execution state as unresolved until account evidence establishes what happened.
Sending a second unrelated order can create additional exposure if the first one actually succeeded. The practical task is reconciliation, not simply making the error message disappear.
Distinguish known rejection from unknown outcome
MetaQuotes lists separate trade-server return codes for different outcomes, including timeout and rejection conditions. Read the actual code and context rather than grouping every failure under order not placed.
An application can also lose the network response after the broker has accepted an operation. Its local screen and the broker may temporarily disagree.
Record the account, exact symbol, side, requested volume, order type, timestamp, and available operation reference. Keep credentials and unnecessary personal identifiers out of diagnostic notes.
Reconcile the relevant broker records
| Evidence | What it can establish |
|---|---|
| Pending orders | A request may have created an order awaiting activation |
| Open positions | Exposure may already exist |
| Order and deal history | An operation may have filled, failed, expired, or closed |
| Broker acknowledgement | A specific server response for the request |
Check all relevant states. An absent open position does not establish failure if the request created a pending order, or if a position opened and closed before you inspected it.
Use actual identifiers where possible. A similar symbol and volume alone may match an unrelated manual trade, particularly on accounts with several strategies or netted exposure.
Separate retrying an operation from creating a new one
A retry mechanism can use an idempotency reference so the service recognizes the same intended operation instead of treating each delivery as a separate instruction. Its guarantees depend on the service implementation and consistent reference handling.
Creating a new trade idea, clicking a separate manual order, or changing to another account is not necessarily the same operation. Do not assume a protection attached to one reference covers all those alternatives.
If the outcome remains unknown, preserve the evidence and resolve the account state through supported controls or provider support. Do not invent a fill or promise that an unverified network path is duplicate-proof.
A hypothetical duplicate-exposure example
Suppose the first requested position is 0.20 lots and would have $40 of planned price risk under the original inputs. If an unrelated second 0.20-lot order also fills at equivalent conditions, combined planned price risk becomes $80.
On a netting account the screen may show one 0.40-lot position rather than two positions. That does not remove the doubled exposure. On a hedging account the tickets may remain separate.
Costs, different fills, and changed stops can make the actual result different again. Verify volume and protective levels after reconciliation rather than checking only the number of visible positions.
What TickerAI currently implements
TickerAI's ordinary trade-idea execution sends the idea identifier as the broker-service idempotency key. A recognized terminal timeout leaves the idea available for a retry designed to reuse that reference, while its message tells the user to check positions.
That path is different from generating a fresh idea or entering an order directly in MT5. The protection should not be generalized to arbitrary new requests or treated as a substitute for checking broker state.
After a resolved response, compare the returned order or position ticket and actual volume. A broker acceptance can also refer to a pending order rather than an immediate market fill.
Preserve a clear incident record
Save the original request time, operation reference, observed error, reconciliation checks, and final known state. Note any manual action taken during the uncertainty, because it can change what later evidence means.
Use MT5 account modes, pending-order checks, and the journal template for the review. Reliable retry handling is about establishing the actual operation outcome; it does not validate the trade's market direction or guarantee its loss amount.