MQL5 trade server return code

MQL5 Error 10024: Too many requests

MQL5 error 10024 is TRADE_RETCODE_TOO_MANY_REQUESTS, the official trade server return code for too many requests. Stop sending on every tick, deduplicate equivalent trade intents, wait for the prior result, and use bounded backoff. The exact server rate policy is broker-controlled, so the repair is request coordination rather than a fixed universal delay. Read MqlTradeResult.retcode after OrderSend because a successful function return does not by itself mean that the order was executed.

Open the Coding Agent and choose MQL5 from the language menu.

Check retcode 10024.mq5
datetime next_send_at=0;

bool MaySendNow()
  {
   datetime now=TimeTradeServer();
   if(now<next_send_at) return false;
   next_send_at=now+2; // local guard, not a broker guarantee
   return true;
  }

void OnTradeTransaction(const MqlTradeTransaction &transaction,
                        const MqlTradeRequest &request,
                        const MqlTradeResult &result)
  {
   PrintFormat("type=%d retcode=%u",transaction.type,result.retcode);
  }
  • Official code: TRADE_RETCODE_TOO_MANY_REQUESTS
  • Meaning: Too many requests
  • Layer: trade server response
  • Verify: MqlTradeResult.retcode

What error 10024 actually reports

The code belongs to MqlTradeResult.retcode, not to the compiler error list and not necessarily to GetLastError. The trade server uses 10024 to report too many requests.

Keep the request, the boolean returned by OrderSend, result.retcode, result.comment, and the symbol properties in the same log record. That separates a client-side request failure from a server-side rejection.

Inspect the request before changing the strategy

Use the smallest failing order and compare every broker-sensitive value with the current symbol and account. Do not hide the error by retrying unchanged input.

  • Count sends per symbol, magic number, and decision event.
  • Prevent a new request while an equivalent request or resulting order is pending.
  • Use OnTradeTransaction to reconcile results rather than polling with repeated sends.
  • Apply bounded backoff and log when the circuit opens or closes.

Repair and verify

Stop sending on every tick, deduplicate equivalent trade intents, wait for the prior result, and use bounded backoff. The exact server rate policy is broker-controlled, so the repair is request coordination rather than a fixed universal delay.

Run OrderCheck with the completed request, log its retcode and comment, then send only if the check is acceptable. OrderCheck improves diagnostics but does not guarantee execution.

Use a focused diagnostic

The time guard illustrates deduplication and the transaction handler records outcomes. Choose coordination rules from the EA state machine, not from an undocumented assumed server quota.

A valid request can still be rejected or filled differently by the trade server. Check the returned retcode, test with the broker symbol and account, and review risk before any live order.

Check retcode 10024.mq5
datetime next_send_at=0;

bool MaySendNow()
  {
   datetime now=TimeTradeServer();
   if(now<next_send_at) return false;
   next_send_at=now+2; // local guard, not a broker guarantee
   return true;
  }

void OnTradeTransaction(const MqlTradeTransaction &transaction,
                        const MqlTradeRequest &request,
                        const MqlTradeResult &result)
  {
   PrintFormat("type=%d retcode=%u",transaction.type,result.retcode);
  }
Where Pineify fits

Repair editable MQL5 source with compiler feedback

Pineify can generate or revise MQL5 source and use MQL5 compilation diagnostics during the coding workflow. Keep the exact error, source location, program type, and intended behavior in the request so the change remains reviewable.

Open MQL5 Coding Agent

Pineify does not run your broker terminal, Strategy Tester, market data, or live orders. Validate the final program in your own MetaTrader 5 environment.

Review MQL5 AI Coding Agent capabilities
Pineify MQL5 AI Coding Agent with an editable MetaTrader 5 code artifact

A practical verification workflow

  1. 1

    Capture the complete result

    Log the OrderSend return value, result.retcode, result.comment, symbol, order type, volume, price, stops, and filling mode. Confirm that the retcode is 10024.

  2. 2

    Read current constraints

    Query the symbol and account immediately before building the request. Broker constraints can differ between symbols and sessions.

  3. 3

    Change the invalid field

    Stop sending on every tick, deduplicate equivalent trade intents, wait for the prior result, and use bounded backoff. The exact server rate policy is broker-controlled, so the repair is request coordination rather than a fixed universal delay.

  4. 4

    Check, send, and retest

    Call OrderCheck, submit the corrected request, then reproduce it in Strategy Tester and a demo account before considering live use.

Frequently asked questions

What does MQL5 error 10024 mean?

It is TRADE_RETCODE_TOO_MANY_REQUESTS, the official MQL5 trade server return code for too many requests.

Is 10024 a GetLastError code?

Treat it as a trade server return code when it appears in MqlTradeResult.retcode. GetLastError reports the terminal runtime error layer, which is a separate diagnostic channel.

Does OrderSend returning true mean the trade executed?

No. The official OrderSend reference says true means the request passed basic checks and was accepted for processing. Inspect result.retcode and subsequent trade events to determine the outcome.

Last verified against the linked official references on . Compile and test the final source in the MetaTrader 5 build, broker, symbol, and account environment you plan to use.

Continue with reviewable MQL5 source

Provide the exact diagnostic and intended behavior, inspect the generated change, compile it, and verify it in your MT5 test environment.

Open MQL5 Coding Agent