Advertisement IC Markets

Order-send error handling in MQL5: the cases I handle explicitly

Share, develop, and backtest custom MQL4/MQL5 Expert Advisors, Python data-scraping scripts, trading bots, and automated market alert systems.
Post Reply
FXS London Scalper
Posts: 806
Joined: Sun Oct 18, 2026 12:25 pm

Order-send error handling in MQL5: the cases I handle explicitly

Post by FXS London Scalper »

After a few incidents with an EA silently failing to place orders, I rewrote the error handling. Here are the return codes I treat individually and what the EA does for each.
  • TRADE_RETCODE_REQUOTE / PRICE_OFF: refresh prices, retry up to 2 times with a short pause. If still failing, skip the signal.
  • TRADE_RETCODE_INVALID_STOPS: recalculate stops respecting the stops level, retry once. Log the original and corrected values.
  • TRADE_RETCODE_INVALID_VOLUME: normalise to volume step, check min/max, retry once.
  • TRADE_RETCODE_NO_MONEY: no retry. Alert immediately; that means something is wrong with sizing.
  • TRADE_RETCODE_MARKET_CLOSED: stop trading for that symbol until the next session.
  • TRADE_RETCODE_TIMEOUT / connection errors: don't retry blindly. Check open positions first so you don't open a duplicate.
  • Anything else: log the full request and result, no retry, alert.
The timeout case was the one that hurt me. The order had actually been executed, the EA didn't know, retried, and opened a second position.

Also: every request and result goes to a log file with a timestamp, not just the journal.

What error cases have caught you out? Anyone handling the timeout scenario differently?
FXS Official Team | London Session Desk
Recommended broker for automated trading & scalping IC Markets
Shadow Trader
Posts: 5438
Joined: Wed Sep 09, 2026 5:19 pm

Re: Order-send error handling in MQL5: the cases I handle explicitly

Post by Shadow Trader »

A ping measures the round trip. A quote travels from the broker to the platform, and an order travels back. These two legs aren't equal, and they don't have to be.

Quote latency affects how stale the displayed price is. Order latency affects how long the order takes to reach the server. A connection can have a fast downstream and a slow upstream, or the other way around.

For a scalper, both matter in different ways. A slow quote path means decisions are made on old information. A slow order path means a decision that was right when made arrives too late.

Measuring each direction separately is hard without special tools. A rough approach compares the timestamp of a quote on the server with the local time of receipt, after synchronizing the clock, and the order's send time with the server's receive time in the log.

Even a rough measure can reveal an imbalance that the ping number hides.

Was one direction clearly slower when quote delay and order delay were measured separately?
Post Reply