forex-scalping.com

Handling trade context busy errors in MQL4

In MT4 only one EA at a time can send a trade request through the terminal. If two EAs on different charts try to send at the same moment, one gets error 146, trade context busy.

It's an old limitation and it catches people running several EAs, or one EA on several charts.

The basic handling is a loop that checks IsTradeContextBusy before sending, waits a short time if it's busy, and tries again for a limited number of attempts. Something like up to ten checks, fifty milliseconds apart, then give up and log it.

A few details matter more than the loop itself.

Refresh prices after waiting. If the EA waited half a second for the context, the bid and ask it calculated earlier are stale. Call RefreshRates before building the order, otherwise you'll get requotes or invalid price errors on top of the busy error.

Don't wait forever. An EA that loops indefinitely on a busy context can freeze its chart and miss its own exit logic.

If several EAs regularly collide, consider using a global variable as a simple lock, so they take turns explicitly instead of all hitting the context at once. Or move to MT5, which handles concurrent requests differently and mostly removes this specific problem.

Some brokers also limit the number of requests per second, so a burst of retries from several EAs can get the account throttled. That's another reason to keep the retry count modest and the delay between attempts reasonable.

Log how often the error happens and which EAs are involved. If collisions happen several times a day, it's usually because multiple EAs are reacting to the same event, such as a new bar opening on every chart at the same second. Adding a small random delay of a few hundred milliseconds at the start of each new bar's processing can spread the requests out enough to avoid most collisions. It doesn't change the trading logic in any meaningful way for M5 or M15 strategies, and it's a simpler fix than building a full queue system between EAs on the same terminal.

A global variable lock needs to be handled carefully. If an EA sets the lock and then crashes or is removed from the chart before releasing it, every other EA will wait forever. Storing a timestamp with the lock and treating any lock older than a few seconds as expired avoids that. GlobalVariableSetOnCondition is the function to use for setting it, because it checks and sets in one step, which stops two EAs from both thinking they got the lock at the same moment. Without that atomic step, the lock just moves the race condition rather than removing it. Test the lock by removing one EA from its chart while it holds the lock and checking that the others carry on after the timeout. If they don't, the expiry logic has a bug, and it's far better to find it on demo than with live money running.

Closing orders matter more than opening ones. If the context is busy when an EA tries to open a trade, the worst case is a missed entry. If it's busy when the EA tries to close a trade or move a stop during a fast move, the result can be a much larger loss. Some developers give closing logic more retry attempts or a longer timeout than opening logic for that reason. It's a simple way to prioritise the actions that protect the account over the actions that just add new exposure, which seems like the right order of priorities.

Error 146 shows up most when several EAs react to the same event, which is often the London open or a data release. A small random delay before retrying helps, since EAs using the same retry interval can keep colliding. Moving to MT5, where the limitation does not exist in the same way, is another option for anyone running many EAs. On MT4 it is also worth having the EA log every busy error with the time, to see whether collisions cluster at specific moments.

Running each EA in a separate terminal instance avoids the problem entirely, since each terminal has its own trade context. Many traders running several strategies do this on a VPS, with one MT4 installation per strategy. It uses more memory, but it also isolates the EAs from each other, so a crash or freeze in one doesn't affect the others. For anything more than two or three EAs on one account, separate terminals are often cleaner than trying to make them share one context politely. It's also easier to restart one strategy without touching the others. A VPS with enough memory for several terminals isn't expensive, and the separation makes troubleshooting a lot easier.

MetaTrader 4 processes trading operations in a way that's effectively single-threaded within a terminal. If an expert advisor is busy placing or modifying an order, other trade requests wait. Under load, such as multiple EAs on the same terminal reacting to the same news tick, requests queue up.

The effect is subtle. An EA that works fine on one chart starts lagging when ten more are attached. A manual order clicked during an EA's heavy processing sits for a second before leaving. The "context busy" error, familiar to anyone who ran multiple EAs, is the platform telling the user it can't handle two things at once.

Workarounds are mostly structural. Running separate terminals for separate strategies spreads the load. Reducing indicator calculations on every tick helps. Avoiding unnecessary order modifications keeps the queue short.

MT5 improved this with a more modern architecture, though poorly written EAs can still cause delays.

None of this shows up on a ping test. It's an internal bottleneck that looks like broker latency from the outside.

Some of the workarounds are surprisingly cheap. Splitting EAs across terminals installed in separate folders spreads the CPU load. Reducing the number of symbols loaded into Market Watch cuts the volume of tick handling. Trimming indicators on charts that only exist for display reduces recalculation.

The EA code matters too. Heavy use of history loops on every tick, repeated calls to account-info functions, and unnecessary chart redraws all slow the processing. A well-written EA does its calculations once per bar when possible, and only checks the price on each tick.

For anyone running more than a handful of EAs, a timing log is worth adding: how long each tick handler took, in microseconds. Spikes in that log point to the culprit. Often it's one badly behaved indicator, not the strategy itself.

Anyone seen the "trade context busy" error in a live session, and what set it off?