Discussing the article: "OrderSend retries and circuit breaker in MQL5"

[MetaQuotes]

Check out the new article: OrderSend retries and circuit breaker in MQL5.

Volatile-market failures such as requotes, connection drops, and partial fills expose a common weakness in EAs: unclassified retries and no cumulative failure control. This article introduces CRetryExecutor with exponential backoff and explicit error classification, plus a three-state CCircuitBreaker with cooldown and half-open probes, unified in CExecutionGateway. You can plug it into an EA to stop futile retries, prevent duplicate submissions, and improve diagnostics.

A production Expert Advisor running live during high-volatility news will encounter failure sequences that most EA code is not designed to handle. The broker rejects the first order submission with TRADE_RETCODE_REQUOTE. The EA's OnTick() handler retries immediately — still requoted. A third attempt arrives while the terminal's connection is momentarily interrupted — TRADE_RETCODE_CONNECTION. By the fourth attempt, the spread has widened beyond the EA's filter and the entry is missed entirely. Meanwhile, a second tick has arrived, triggering the same OnTick() path again. The EA now submits two orders in rapid succession for the same signal, creating a doubled position that no risk management logic anticipated.

This is not an edge case. It is the normal behavior of volatile markets. The problem is not that failure happens — broker-side transient failures are unavoidable. The issue is that many EAs handle failures ad hoc: Sleep(500), local retry loops, and GetLastError() checks that treat all errors the same. These patterns share three deficiencies. First, they do not classify errors. A requote is transient and should be retried; a margin rejection is permanent and must not be retried. Retrying permanent failures wastes time and risks duplicate submissions. Second, they do not track cumulative failure state: if the broker's execution system is genuinely overloaded or the terminal's connection is degraded, individual retry loops have no awareness that five consecutive failures have occurred and that further submissions should be suspended. Third, they are not reusable: the retry logic is duplicated across every place in the EA that calls OrderSend(), meaning that a fix in one location does not propagate to others.

This article presents a structured solution in three composable layers. CRetryExecutor wraps a single OrderSend() call with configurable retry count, exponential backoff delay, and systematic error classification that separates transient failures from permanent rejections. CCircuitBreaker tracks consecutive failure counts across multiple submission attempts and blocks further submissions after a configurable threshold, entering a half-open probe state after a cooldown period to allow controlled recovery. CExecutionGateway composes these two classes into a single submission interface whose behavior is fully specified by two configuration structs. Two verification scripts and a demonstration EA show the system operating under simulated and unit-tested conditions.

Author: Ushana Kevin Iorkumbul