MT5 code 10006: test 3 states before adding a retry

Your retry needs a known starting state. My MT5 run passed 3 synthetic return-code checks and sent zero orders. That is a small check for a local classifier. It gives a retry routine three different starting states before that routine is allowed anywhere near a real account.

I keep rejection, placement and completion separate before considering another request. Here is how I would turn that rule into a test you can inspect, including what the test cannot establish.

Start with the question the retry must answer

A trader asked how to check a failed Python order and send it again. The reported code was 10006. There was no useful explanation in the journal. A retry sounds like the next practical step, but it depends on an earlier question: what state did the previous submission reach?

The official OrderSend documentation separates the function returning true from the market trade actually completing. The Python order_send example also exposes the returned structure and original request. Those are useful inputs to a receipt. They do not make every received result a fill.

Write three expected cases before a retry loop

My first case uses synthetic code 10006. The expected label is REJECTED_REASON_UNKNOWN. The rejection remains visible, and its cause stays unknown. This case must fail if a future edit silently turns that number into permission to resend.

The second case supplies synthetic code 10008. Its expected label is PLACED_NOT_FILLED. Placement is a separate state. The next operation needs the relevant order record, rather than another submission based on an assumption that nothing happened.

The third case supplies synthetic code 10009. Its expected label is COMPLETED_RECONCILE_DEAL. Completion still leads to checking the corresponding account record. The name deliberately carries that next obligation instead of reducing the result to a cheerful success message.

These are three chosen inputs, not three observed trades. They are enough to catch accidental merging of the three local branches. They do not cover every return code or account transition.

Keep the tested function small

This original MQL5 function maps a supplied number to a label:

string Classify(uint code)
{
   if(code==TRADE_RETCODE_REJECT)
      return "REJECTED_REASON_UNKNOWN";
   if(code==TRADE_RETCODE_DONE)
      return "COMPLETED_RECONCILE_DEAL";
   if(code==TRADE_RETCODE_PLACED)
      return "PLACED_NOT_FILLED";
   return "UNCLASSIFIED_RECONCILE";
}

The last branch keeps an unfamiliar number visible. It does not silently treat missing coverage as success. The function has no account side effect, so its comparisons can be checked without placing an order.

Read the native receipt within its limits

The native runtime receipt records three passing comparisons, orders_sent=0 and server_reject_reproduced=false. MT5 executed the script; the screenshot uses a EURUSD chart as its capture surface.

This proves the local mapping for the three supplied numbers. It does not reproduce the trader's rejection, diagnose a broker setting or prove a safe automatic retry policy. There was no OrderSend or OrderCheck call in this test. A local classification check cannot answer why a different account rejected a request.

Add the account evidence before automating the next step

Open one rejected request and compare its returned code, comment, order and deal fields with its original request and timestamp. Keep the requested symbol, volume, order type and prices alongside them. Preserve an external return code when one is present.

Then define what the next step must observe for that operation. A placed order needs its order state. A completed request needs the corresponding deal or account change. An unexplained rejection needs the missing reason investigated. A transport interruption needs reconciliation before a second submission can be considered.

Keep one attempt identifier for each actual submission. It helps connect the receipt to later records without confusing one trading intention with two separate attempts. Test those joins and transitions with their own positive and negative cases before adding an automatic retry.

The FIX-15 proof page retains the original native example. For a bounded review of your own readable source and one expected result, use the Free EA Code Check.