MT5 · code and request checks
MQL5 error 4756: keep the local error and server return code
Your EA can print error 4756 and hide the server's more specific return code. My MT5 run passed 4 local log checks and sent zero orders. I keep both numbers before changing a request.
Arnold Holm · 2026-10-18
What the error means
An EA is a program that applies your trading rules in MetaTrader. The runtime error 4756 means trade request sending failed. GetLastError reads that local error number. A trade result also has its own retcode field. Those fields answer different questions, so a useful failure log preserves both. Printing one number and discarding the other removes evidence you may need for the next step. The original trader question used OrderSendAsync and reported local error 4756 together with retcode 10013. Its request mixed a stop-loss modification action with a pending-order type. That is the question's reported code and log, not a failure reproduced by my small test. It shows why the local number alone is too little information. This page does not claim to repair that asynchronous request or to identify every invalid field. The official OrderSend documentation makes a second distinction. A true return value does not by itself mean a trade was executed. The result code must be checked, and execution can produce later trade events. A local logging helper cannot replace that order-state handling. It can make the first log line less ambiguous while leaving the actual server result visible. I start with a repeatable log check because it costs no orders. Give the formatter fixed inputs and compare the whole output, including false, zero and empty values. Once that small boundary works, use the same fields when investigating an actual authorised request. Do not turn a log helper into a reason to resend an order.
Three code paths to check
1. Only GetLastError is printed.
Keep the function's Boolean return value, the local error read immediately after the relevant call, the trade result retcode and its comment together. Reset the local error before the operation so an older failure does not get attached to a later request. Preserve the original result before another operation changes the surrounding state.
2. Different server errors are flattened into one message.
The official return-code table names 10030 as invalid order filling type and 10016 as invalid stops. A log containing only 4756 cannot preserve that difference. These are synthetic inputs in the test below, not observed broker rejections. For a real incident, inspect the code actually returned for the exact request, symbol and account.
3. A missing result becomes an invented diagnosis.
If the captured server code is zero and the comment is empty, keep them that way. Do not replace the missing result with a guessed filling or stops error. Record the request action and the relevant fields separately. An asynchronous path also needs its own event correlation; this formatter neither waits for later events nor decides whether a retry is safe.
Four fixed log cases in native MT5
I compiled and ran this original formatter in MT5 build 6230 on 18 October 2026. All four exact-string comparisons passed. The first synthetic case combined false, local 4756, server 10030 and Unsupported filling. The second kept the same local number but server 10016 and Invalid stops. Their output stayed distinct. The third case used false, 4756, zero and an empty comment. It checked that missing server detail remained visible rather than acquiring a made-up explanation. The fourth used true, zero, 10009 and Request completed. It checked the formatter's success-shaped input, without claiming that a real order had completed. The input strings are fixed test inputs; the runtime did not obtain them from a broker. The terminal screenshot shows the four comparisons and the final pass line. The source calls neither OrderSend nor OrderCheck. This is a native local test of keeping all four fields. The chart behind the output is a terminal background, not a trading-performance result.
string Diagnostic(bool sent,int local_error,uint server_code,string server_comment)
{
return StringFormat("sent=%s local_error=%d server_retcode=%u comment=%s",
sent?"true":"false",local_error,server_code,server_comment);
}Four synthetic local formatting checks, zero orders and no 4756 reproduced. No broker rejection, asynchronous lifecycle or retry policy was tested.
How you know it is fixed
Keep two different rejection inputs distinct
Compare the two fixed outputs for server codes 10030 and 10016 while local error remains 4756. Each output must retain its own server code and comment.
Preserve empty information
Use server code zero and an empty comment. The output must keep those values, with no substituted diagnosis or instruction to retry.
Your five-minute log check
Open one failed request log. Can you find the Boolean return, immediate local error, result retcode and result comment together? If one is missing, add that field to the log line before changing the request. Keep the actual request fields and later trade events alongside it.
Your own source
Find the next line to check
Start with the free EA-Check. Your code stays in your browser. It highlights patterns with line numbers; it does not prove the broker accepts an order.
Want one small change shown on your own case?
R49: one authorised, reproducible MT4/MT5 defect in readable source up to 500 lines, with three agreed cases. 49 USD fixed. Delivery within 48 hours after source review and funding. The exact case is agreed before funded work.
Send the expected and actual behaviourRelated checks
Common questions
Does 4756 mean I should change the filling policy?
The local number alone does not establish that. Preserve the actual server return code, comment and request fields before deciding what to change.
Did this test reproduce a failed trade?
No. It passed four synthetic local formatting cases. It made no trade request and tested no broker response.
Sources and limits
- Original trader question: OrderSendAsync, 4756 and 10013
- Official runtime errors: ERR_TRADE_SEND_FAILED
- Official OrderSend return and result handling
- Official trade-server return codes
- Native local run: four checks and zero orders
These public questions explain the error; use your own EA log to check whether the same cause applies.