Your EA can put the wrong filling policy into a perfectly valid integer. My MT5 run passed 6 local filling-value checks and sent zero orders. The useful detail was a collision: the symbol capability flags were 3, and ORDER_FILLING_BOC was also 3. Those equal numbers describe different things.
A trader's original error report showed a large negative filling value beside an invalid-request result. The author later reported success after explicitly choosing IOC. That gives us a concrete debugging question: where did the value come from before the request was sent? Copying the final setting into another bot skips that question.
The conversion I would look for first
This is the tempting assignment:
request.type_filling =
(ENUM_ORDER_TYPE_FILLING)SymbolInfoInteger(symbol, SYMBOL_FILLING_MODE);
It compiles because an explicit cast permits the conversion. But SYMBOL_FILLING_MODE describes capabilities through flags. The request field expects one named policy. A cast changes the type the compiler sees. It has not translated a set of capabilities into a permitted policy for this order.
In my native run, the symbol flags were 3. The named order values were FOK 0, IOC 1, RETURN 2 and BOC 3. A raw cast would therefore make that particular capability mask look like BOC. BOC is a passive filling policy, with its own order-type and symbol conditions. A market order has not become eligible for it because both values print as 3.
Separate integer validity from permission
I wrote and ran this small guard before considering policy selection:
string FillingState(long raw)
{
if(raw==(long)ORDER_FILLING_FOK || raw==(long)ORDER_FILLING_IOC ||
raw==(long)ORDER_FILLING_RETURN || raw==(long)ORDER_FILLING_BOC)
return "KNOWN_ENUM_CHECK_CONTEXT";
return "INVALID_ENUM_NO_REQUEST";
}
The output deliberately has two meanings. A value outside the named constants stops here. A known constant still needs the execution mode, order type and symbol capabilities checked. I keep those states separate because a boolean named ValidFilling can quietly grow into permission to send.
Two inputs, -370154256 and 999, returned INVALID_ENUM_NO_REQUEST. Each of the four named constants returned KNOWN_ENUM_CHECK_CONTEXT. All six comparisons passed in MT5 build 6230. The program also read the current EURUSD symbol capabilities and execution mode separately, so the log preserved the numbers that could otherwise get mixed together.
Check the caller as well as the helper
A useful early guard can still be defeated by its caller. Search for every assignment to type_filling, rather than inspecting only the last line before OrderSend. Check whether a structure was initialised, whether a helper overwrote the value, and whether a default branch reuses a stale request.
Then follow the known-enum path. The official filling-policy table matters here. RETURN is unavailable for Market Execution. BOC has its own supported order types. Knowing a constant exists says nothing about whether this particular request should use it. I do not choose IOC simply because it fixed another trader's example.
My five-minute check is this: open one failed request log and write down its symbol, order type, type_filling, symbol flags, execution mode and actual returned code. Trace where type_filling was assigned. If a raw mask was cast directly into it, separate the capability read from the named choice before another test.
The original question, official policy table and native output let you check the example. The screenshot below shows the actual local run.
If you have a small reproducible trading-bot defect, the free bug check is a way to start with the failing case.
This run checked local integer handling, sent no requests and did not reproduce server error 10013 or validate a complete order.
