Persistent Order Lifecycle State Machine

Most EAs assume they know what every ticket they hold is currently doing, because the EA itself opened it. That assumption fails constantly: a stop loss fires while nobody is watching, a pending order expires, the terminal loses its connection for ten minutes, or the terminal restarts after a crash. When the EA comes back it resumes from whatever it last remembered, which by then may be wrong, and nothing built into the platform flags the discrepancy on its own. This library solves that by making a ticket's state a durable fact rather than an assumption held in memory. Track() records the state the moment a ticket starts being watched. Sync() re-derives what state the ticket is actually in right now and compares it against what was last recorded. A change - PENDING to OPEN, OPEN to CLOSED, PENDING to DELETED, or a ticket that has vanished entirely (LOST) - is written immediately to two files: a snapshot of the latest state per ticket for fast recovery, and an append-only audit trail of every transition ever observed, timestamped, that is never rewritten or pruned. The LOST state matters as much as the others. A ticket Sync() cannot find anywhere usually means the account's history depth does not reach back far enough, or a broker purged an old expired order outright. Either way, silently continuing with a stale picture is worse than surfacing an explicit "I no longer know what this is." The library never sends, modifies or closes anything. It observes only, so it can sit alongside any trading logic already in place without owning any part of the send path. Notes and limitations - On MQL4, Sync() relies on OrderSelect(ticket, SELECT_BY_TICKET), which searches both the trade and history pools; on MQL5 it relies on the same full-history HistorySelect(0, TimeCurrent()) plus HistoryOrderSelect(). On either platform, if the terminal's configured history depth does not reach back far enough, an old ticket can appear LOST even though it genuinely closed - widen the terminal's history range if this matters for old tickets. - A pending order found in history without ever filling is reported DELETED on both platforms. Neither header distinguishes manual deletion from broker-side expiry; both surface as DELETED. - This is an observation library, not a trading library, on either platform. It never sends, modifies or closes anything - reacting to a transition is entirely the caller's responsibility. - File I/O happens on every state-changing call on both platforms. For very large baskets synced every tick, consider syncing on a timer instead of every OnTick/OnTick-equivalent. - On MQL5, a caller who tracks a pending order ticket and then wants to keep tracking it through a fill must, once Sync() reports the transition (from PENDING toward CLOSED/DELETED via ORDER_POSITION_ID), separately Track() the resulting position ticket if the position itself also needs watching - the original pending order's own history record does not turn into the new position's live tracking automatically.

Script · MT5 · v1.0 · Free

Tags: Pending Orders · MT5 Script · MQL5 Source Code

MQL4 & MQL5 scripts · PolyMaria