DEV Community: Arnold Holm

Which loss limit leaves less room for your next trade?

Arnold Holm — Sun, 01 Nov 2026 09:20:09 +0000

In this invented example, 100 USD total room is tighter than 300 USD daily. If you track two fixed floors on one equity number, you compare your next loss to both gaps.

A Reddit thread discusses daily drawdown or a consistency rule (daily drawdown or consistency rule discussion). This piece does not answer consistency rules. It is only an arithmetic illustration motivated by that drawdown discussion.

The numbers

Equity is the account value including open trades. Here it is 9,600 USD. The case sets a fixed total floor at 9,500 USD and a fixed daily floor at 9,300 USD on that same equity basis.

Equity USD	Total floor USD	Daily floor USD
9,600	9,500	9,300

Total room is 100 USD. Daily room is 300 USD. A loss must stay above both floors at once, so the smaller positive room sets how far the next loss can go before it crosses a line.

You can see it in two subtractions. 9,600 minus 9,500 leaves 100 USD. 9,600 minus 9,300 leaves 300 USD. Now subtract the next loss from equity first. Then compare that new equity with each floor. A 120 USD loss leaves 9,480 USD. That is below 9,500 USD and above 9,300 USD. So the daily gap alone would have missed the breach. The total gap decides here because it is smaller.

300 USD daily room covers a 120 USD loss. 100 USD total room is exceeded at 9,480 USD, 20 USD below the total floor and 180 USD above the daily floor. I never use the larger buffer alone.

Python check

This function does pure subtraction and returns both gaps plus a position tag. It places no trade and opens no broker connection. It only subtracts numbers you type in. Three arithmetic checks passed.

def rooms(equity, total_floor, daily_floor):
    return {
        "total": equity - total_floor,
        "daily": equity - daily_floor,
    }

def position(equity, floor):
    if equity > floor:
        return "above"
    if equity == floor:
        return "at_floor_check_rule"
    return "below"

assert rooms(9600, 9500, 9300) == {"total": 100, "daily": 300}
assert 9600 - 120 == 9480
assert (position(9480, 9500), position(9480, 9300)) == ("below", "above")

Equality returns a tag that asks for the written rule. The code does not call that tag safe.

I put the two floors side by side before I judge room. I take both numbers from written rules. I put them on the same equity basis. Then I subtract each floor from current equity. The smaller positive result is the tighter gap. That is the gap I check first in this invented case.

Cases near the total floor

Start again from 9,600 USD and test three hypothetical losses against the 9,500 USD total floor. A 99 USD loss leaves 9,501 USD, above the floor. A 100 USD loss leaves 9,500 USD, exactly on the floor and allowed only if your firm wording permits equality. A 101 USD loss leaves 9,499 USD, below the floor. Equality is not automatically safe. Your written rules decide if touching the floor counts as a breach.

Your rules

This case uses fixed floors only. Fixed means the floors stay at 9,500 USD and 9,300 USD in this case. They do not follow equity up or down. A trailing floor moves with the account under its own written rule and needs its own peak in the account. Do not reuse these fixed numbers for it.

Room left is not allowed risk. Commissions, slippage and changing equity can shrink room before or during the next loss. This is no sizing instruction. Fees, floating P/L, resets and equality come from your actual written rules. I write both floors down first. Write both floors from your rules on the same equity basis and compare the smaller room.

The optional free Pre-Check, the free Prop Rule Guard, can help organise the written rules.

This invented case is not firm terms, not live broker records and not a pass test.

Error 136: another retry is not a quote check

Arnold Holm — Sat, 31 Oct 2026 08:33:34 +0000

My native MT4 run passed three synthetic policy cases with zero order calls. If your EA keeps hitting off quotes, you still need a quote check first.

This is a small policy check after error 136. A synthetic check with no orders cannot prove a broker cause and cannot show that retries fail.

The forum thread

A trader asked why 10 to 15 repeated OrderSend attempts still return error 136. See the MQL5 forum.

James said 10 to 15 attempts still returned the same error. His helper read the chart price for the passed pair. A reply said that mix uses the wrong price when symbols differ. James fixed that line, but he trades only the chart symbol now. So that fix does not explain his failures. Without per attempt symbol, prices, quote time and error, the cause stays open.

Many EAs assume this. Repeating the request will eventually solve off quotes. My rule says the opposite. A new attempt needs a usable quote and a still-valid signal.

What my policy check did

I ran a native check in MT4 4.0.0.1491. It compiled with zero errors and zero warnings. It ran in the Strategy Tester on offline EURUSD H4 supplied history with fixed spread 20 points.

Zero quote inputs returned NO_RETRY. Expired signal inputs returned NO_RETRY. Fresh inputs returned ELIGIBLE_ONCE, then NO_RETRY with alreadyConsidered at 1.

Three chosen cases, not full coverage. The five second and one consideration limits are illustrative, not universal.

if Bid <= 0 or Ask < Bid: return NO_RETRY
if quote_age_sec > 5 or quote_time > now: return NO_RETRY
if now > signal_expiry: return NO_RETRY
if alreadyConsidered >= 1: return NO_RETRY
return ELIGIBLE_ONCE

The function does no waiting, no persistence, no network access, no orders and no duplicate checks. Your caller must keep its own count. Eligibility only allows one more review of all execution checks, never a trade by itself.

Why I check first

I check the quote and the still-valid signal before considering another attempt. If the quote is missing or unusable, I stop. If the symbol is wrong, I stop. If the signal or count is spent, I stop.

Check your next result

On your next off quotes result, write request symbol, Bid and Ask, quote time, signal expiry, captured error 136 and attempt count in one line. Missing or disordered prices mean no further review of that attempt.

Confirm the price read uses the order symbol. Compare now with expiry and read your kept count. If any check fails, keep the record and wait for a fresh idea.

What this check does not show

Three chosen cases, zero order calls. Error 136 was not reproduced or fixed. No broker, execution or profit claim.

Original website article with tester proof.

MT4 OrderModify error 1: skip a stop update that changes nothing

Arnold Holm — Wed, 28 Oct 2026 14:39:34 +0000

Your trailing stop can skip an unchanged update: my native MT4 test returned error 1 for the same stop, then error 0 after a real change. If you see error 1 on every tick, check stored and requested values before you change code.

What the error means

A trader asked: "Why does OrderModify keep reporting error 1 when I change the stop value?" A follow-up asked if an unchanged stop would also block a take-profit change. Those are different requests.

An unchanged intended request can be skipped before the call.

I compare the complete intended change before calling OrderModify.

The official MQL4 reference calls error 1 ERR_NO_RESULT. Passing unchanged values can produce it. It does not say every field must change. A new take profit can still matter while the stop stays put. Open price and expiration can change only for pending orders.

I ran the unchanged-stop case in the native MT4 Strategy Tester on EURUSD H4. It opened one simulated BUY 0.10 at 1.2054 with stop 1.1934. It called OrderModify with the same open price, stop and target. It returned false with immediate error 1. It then moved the requested stop to 1.1944. That call returned true with immediate error 0, and a fresh selection read back 1.1944. The position closed inside the tester at 1.2034 with zero account orders.

A trailing rule can print the same valid target on many ticks. The candle low can stay flat, or rounding to the symbol increment can erase a tiny move. Logging error 1 each time hides what matters: stored value, requested value, and whether they differ.

Three checks before you edit

Stored target already matches

Read the order again and compare stored and intended values at symbol precision. Do not trust a rounded chart label.

Stop-only test hides a target change

Compare take profit too. An unchanged stop does not mean the whole request is unchanged. My native run covered only the stop path. Test a target-only change separately.

Stale error looks current

Check the return value. Clear the error before the call and read GetLastError right after a fail, before another call replaces it. Keep request and result together.

Compare both fields, then validate the rest

The helper below expects valid prices on the symbol increment. Zero can mean no stop or target. A false result means do not call. It never means remove protection.

Use the order symbol increment, select the right ticket, and keep the market open price. Then run your own distance, freeze, direction and account checks. A different price is not automatically an allowed price. The helper does not choose a stop, round a price, select an order or send a request.

bool StopPairChanged(double currentSL,double currentTP,
                     double targetSL,double targetTP,double tickSize)
{
   if(!MathIsValidNumber(tickSize) || tickSize<=0) return false;
   if(!MathIsValidNumber(currentSL) || !MathIsValidNumber(currentTP) ||
      !MathIsValidNumber(targetSL) || !MathIsValidNumber(targetTP)) return false;
   return MathAbs(currentSL-targetSL)>tickSize*0.5 ||
          MathAbs(currentTP-targetTP)>tickSize*0.5;
}

The picture shows the real tester run. Its single-price check uses Point for this supplied EURUSD dataset. The two-field helper is for review only. It did not run in that test case. Do not read the picture as a test of every helper branch.

How you know it is fixed

Unchanged call must return false with immediate error 1, then skip. Changed call must return true with immediate error 0, and a fresh selection must show 1.1944.

Your five-minute source check

Find OrderModify in your trailing branch. Print the selected ticket, current stop and target, intended stop and target, symbol increment and immediate result. Check that a target-only update is not lost behind a stop-only equality test.

Common questions

Does error 1 mean the trailing stop is broken?

It can mean that this call requested no change. Inspect the current and intended values before changing your trading logic.

Must both stop loss and take profit change?

No. One genuine parameter change can make the request meaningful. The unchanged-value condition concerns the request as a whole.

Does a true comparison guarantee a successful modification?

No. Stop distances, freeze rules, order state and server conditions still matter. Check the actual function result and stored order values.

Sources

Original OrderModify error 1 question with stop and target follow-up

Original article and free EA check

Native MT4 offline/default tester test case on supplied EURUSD H4 history, fixed 20-point spread, zero account orders sent. No broker acceptance, live execution or strategy performance is established.

A 100 USD counter example: when your reset starts an hour too early

Arnold Holm — Tue, 27 Oct 2026 11:58:44 +0000

On 25 October, a hardcoded 22:00 UTC reset could have erased a hypothetical 100 USD daily loss from your counter one hour early. That code would have started the next rule day one hour early on 25 October 2026.

Eight original offline clock checks from 25 October 2026 passed. This is a clock check about rule dates.

Start with the written reset rule

The question is simple. How is the limit calculated? The FTMO Academy lesson discusses that question. The current trading objectives describe a recalculation at midnight, 00:00 CE(S)T. CE(S)T means Central European time with its summer change. I use the IANA timezone Europe/Prague for the mappings below. A named timezone carries the change between UTC plus two hours in summer and UTC plus one hour in winter. A fixed offset misses that change.

The local rule date matters. It is not always the date on a broker server, your laptop or an unlabelled UTC log.

Many counters rest on one idea. A daily reset always happens at the same UTC hour. On 25 October the same local midnight maps to a different UTC hour. That shift is the point of this example.

The disputed half hour

At 22:30 UTC on 25 October 2026, the Prague clock read 23:30 with an offset of plus one hour. That was still 25 October. A program that changed its daily counter at 22:00 UTC had already moved to 26 October 2026. It was thirty minutes before the correct local boundary.

In the hypothetical 100 USD example, that program would show a fresh daily counter while the written rule still belonged to the old day. The loss stayed live under the challenge rule. The program had started the next day too soon.

These are three of the saved timestamp cases.

24 October, 22:00 UTC becomes 25 October, 00:00 at UTC+02.
25 October, 22:30 UTC becomes 25 October, 23:30 at UTC+01.
25 October, 23:00 UTC becomes 26 October, 00:00 at UTC+01.

The saved set holds seven timestamp cases plus one check for the elapsed time between those local midnights. That local day lasted 25 hours.

Why a 24-hour timer gives the wrong answer

A common shortcut is to save the prior reset and add 24 hours. Another is to hardcode 22:00 UTC because that matched the prior summer midnight. Both hide the same idea. They assume the UTC span between local midnights never changes.

On 25 October 2026 it changed. The next Prague midnight was at 23:00 UTC. I would calculate the next midnight in the written rule timezone first, then convert that instant to UTC for storage and comparison. I would not silently rename an uncertain server timestamp as UTC.

Check your counter before you rely on it

Use these four steps. They take about five minutes.

Find the timezone and reset wording for your exact challenge product.
Convert the next local midnight to UTC with a timezone database that includes daylight saving rules.
Compare that instant with the firm's dashboard countdown. If they disagree, fix the rule or timestamp source before you trust the local counter.
Test one instant just before the boundary and one exactly on it. The first must keep the old local date. The second must start the new one.

For this example, 25 October 2026 at 22:59:59 UTC was still the old rule day. At 23:00:00 UTC, the Prague date changed to 26 October 2026. That one-second boundary in a repeatable clock check tells you more than a glance at a clock face.

Your own check is the next reset instant and the dashboard countdown. The optional free Pre-Check, the free Prop Rule Guard, can help organise the written rules.

What this check does not show

This clock check from 25 October 2026 shows these mappings only. It does not show breach detection, broker server mapping, live fills or profit. It does not set a loss percent shared by every challenge. It does not show remaining loss allowance under a limit, which also needs exact equity, the account value including open trades, plus open positions, fees and product rules. Check the rule text for your exact product.

Original website article with clock proof.

MT4 error 4107: log the exact price before changing it

Arnold Holm — Mon, 26 Oct 2026 11:35:11 +0000

Your entry can look valid and still fail. My MT4 test returned error 4107 for an over-precise entry, then accepted current Ask.

What the error means

A trader testing XAUUSD reported an invalid price of 2347.42500000. The number looked close to the market. The trader had checked for negative inputs and tried normalization, but the error remained. Without the source and symbol settings, that report does not establish which argument was wrong. A plausible-looking number is not enough to diagnose an OrderSend call.

I start by keeping three things together: the exact request, the function return value, and the error captured immediately after the call. The request includes entry, stop loss and take profit. Looking only at the entry price can miss a problem in a calculated stop or target. Printing fewer decimal places can also hide the input that the function actually received.

The official MQL4 error table lists 4107 as ERR_INVALID_PRICE_PARAM. It separately lists 129 as ERR_INVALID_PRICE and 130 as ERR_INVALID_STOPS. Those numbers should not be swapped in a log or folded into one guessed explanation. The OrderSend reference describes price-thread and precision conditions for 129, and stop-distance conditions for 130. Record the number that your own terminal returned.

I built a small native MT4 Strategy Tester test case to isolate an over-precise entry. On supplied EURUSD H4 history, it first submitted a simulated BUY at Ask plus 0.1234567 of one point. The deliberately altered price returned ticket -1 and error 4107. The next simulated BUY used the current Ask without that extra fraction. It returned a positive ticket and error 0. A fresh order selection confirmed that the stored entry matched Ask within half a point.

The simulated position was then closed inside the tester. No order went to an account. The screenshot is the actual tester output from this run, not a mock trading result. The test case uses one EURUSD dataset and a fixed 20-point spread. It does not reproduce the trader's XAUUSD setup, inspect that person's source, or establish a universal rounding rule for gold.

I diagnose the exact request before adding another retry. A retry with the same invalid input adds no new information. A retry after silently rounding a pending entry can change the trading rule. Keep the original value in the record, identify the field that fails validation, and decide whether a corrected candidate still satisfies the intended rule.

Three code paths to check

An entry calculation adds unsupported precision

In the native test case, adding a fractional point to Ask was enough to produce 4107. For a market BUY, use the current Ask for the actual order symbol. For a market SELL, use current Bid. A calculated pending entry has a different validation path and must retain the intended distance and direction after alignment.

A calculated stop or target is the bad input

Record stop loss and take profit alongside the entry. Check that every nonzero value is finite, has the intended sign and sits on the permitted price increment. Zero can mean no stop or target. Do not reject zero indiscriminately or silently replace a requested protective stop with zero.

Decimal formatting is mistaken for a valid price grid

Digits controls decimal precision. A symbol can also have a tradable price increment that needs separate handling. Rounding to a number of decimal places does not by itself prove that a calculated price is on that grid. Read the symbol specifications and keep point, tick increment and pip conventions distinct.

Keep the failing input and immediate error in one record

The excerpt is deliberately invalid and belongs only in a tester. Its purpose is to show the input that caused this local failure. It is not an EA entry routine. The full test case refuses to initialize outside IsTesting, checks the successful order by ticket, reads back its open price, closes the simulated position and requires every expected result before printing PASS.

The change in this test case was to stop altering a valid terminal quote. It was not a general instruction to round every value. For a real EA, first select the correct symbol and request type. Read fresh prices for that symbol. Validate calculated pending prices and stops against their own requirements. If alignment moves a level, check that the resulting request still represents the rule you intended to trade.

ResetLastError before the attempt and capture GetLastError immediately afterward. Other calls can change the saved error. Treat a failed ticket as a failed attempt, not as an open position. If the request is accepted, select the returned ticket and read the stored values. That gives you evidence of what happened instead of relying on a success message alone.

// Native tester test case only. OnInit rejects !IsTesting().
double badPrice = Ask + Point * 0.1234567;
ResetLastError();
int ticket = OrderSend(Symbol(), OP_BUY, 0.1, badPrice,
                       10, 0, 0, "FIX26 invalid", 260026, 0, clrNONE);
int error = GetLastError();
// Observed in this test case: ticket = -1, error = 4107.
// A separate call using current Ask returned a positive ticket and error 0.

Native MT4 offline tester, supplied EURUSD H4 history, 3 May 2021, fixed 20-point spread. One invalid entry and one accepted simulated entry. No XAUUSD diagnosis, broker execution, latency or strategy performance claim.

How you know it is fixed

Negative case: preserve the deliberately invalid input

Run the supplied test case only in the Strategy Tester. Its fractional-point entry must fail with ticket -1 and captured error 4107 in the documented environment. An unexpected result is a failed test, not permission to change the expected number.

Positive case: read back the accepted simulated entry

The current-Ask call must return a positive ticket and error 0. Select that ticket again and compare its stored entry with the requested Ask. Close the simulated position and keep the complete result log.

Your five-minute source check

Find the failing OrderSend. Print its symbol, operation, entry, stop, target, Digits, Point, symbol price increment, Bid and Ask. Keep enough precision to expose the actual arguments. Check all three price fields before changing rounding or retry behaviour.

Common questions

Does 4107 prove that my broker rejected the order?

The number alone does not establish a broker-side rejection. Keep the exact request and local return value. This offline test case reproduced 4107 without sending any account order.

Will NormalizeDouble fix every invalid-price report?

No. Decimal precision, the symbol price increment, request direction and stop distances are separate checks. The right correction depends on the actual failing field and intended rule.

Did this test solve the original XAUUSD report?

No. The original report did not include enough source and symbol details. This is an independently reproduced EURUSD precision failure with an explicit before-and-after check.

Sources

Original XAUUSD invalid-price question, unresolved source details

Official MQL4 runtime error codes

Official MQL4 OrderSend parameters and return values

Original article and free EA check

Alpaca partial fills: count 7 shares, not 10

Arnold Holm — Sat, 24 Oct 2026 14:41:25 +0000

Your bot should count 7 filled shares after totals of 3 and 7, not 10. In my small local check, adding both totals overstated the order by three shares. That is enough to give you the wrong view of how much of an order remains open.

In A Good Price Is Not Yet a Trade, Sergei B asks: "Which orders went into the count?" His post separates orders with some filled volume from orders with none. That distinction also matters when you read a bot's filled quantity. A good fill price says little if the quantity beside it has been counted twice.

This example uses invented quantities. It does not use Sergei's trading records or claim to repeat his measurement.

Two messages do not mean two new trades

Suppose you ask your bot to buy seven shares. The first message says three have filled. A later message says seven have filled in total. The later seven includes the first three. Only four more shares have filled between those messages.

Alpaca's trade-update documentation distinguishes the quantity of an individual execution, qty, from the order's total filled quantity, filled_qty. Check which field your bot stores before changing the calculation. Adding new executions and reading order totals are different ways to answer the same narrow quantity question.

Message	Shares in this execution	Total shares filled for the order
First partial fill	3	3
Final fill	4	7

You can add the two distinct executions: three plus four makes seven. Or you can read the latest authoritative order total: seven. Adding the two order totals gives ten, which counts the first three twice.

I keep an order's running filled quantity separate from each individual execution. I would stop on an unexplained lower total rather than quietly change the number shown to the trader.

What my local check found

I ran six checks with invented inputs. The first sequence reported three, then seven, and kept seven as the order total. Repeating seven added zero. A second order kept its own quantity. A lower total, a negative quantity and a non-number each stopped the calculation without changing the first order's seven shares.

The picture comes from the output of that local run. The bar marked ten shows the incorrect addition of the two reported totals. It is not an order sent to a broker. You can reproduce the core calculation with Python's standard library:

from decimal import Decimal

class Reconcile(Exception):
    pass

def observe_total(totals, order_id, filled_qty):
    total = Decimal(filled_qty)
    if not total.is_finite() or total < 0:
        raise Reconcile("invalid filled quantity")
    previous = totals.get(order_id, Decimal("0"))
    if total < previous:
        raise Reconcile("lower total: reconcile before changing state")
    totals[order_id] = total
    return total - previous

totals = {}
assert observe_total(totals, "order-A", "3") == 3
assert observe_total(totals, "order-A", "7") == 4
assert observe_total(totals, "order-A", "7") == 0
assert totals.get("order-A") == 7

Check one order in your own history

Compare one order's latest filled total with the sum of its distinct executions, keeping the order identifier the same. Do this on exported history or demo data before changing a running bot. Keep the message order and any execution identifiers with the values, so a repeated message cannot look like a new trade.

Also compare the filled amount with what you originally requested. Seven filled shares out of a seven-share request leaves none open in this example. Three filled out of seven leaves four. Do not mark the whole requested quantity as completed just because one part filled at a good price.

If a later message shows six after seven, investigate. It may be old information, a correction or a mapping mistake. This short check cannot choose between those explanations. Keeping the larger value forever would hide a real correction; trusting whichever message arrives last would hide a delayed one.

This is a check of one order's quantities, not your account's position or a trading result. The code has no lasting storage, reconnect handling or full account comparison, and restarting it loses the dictionary. The six local checks do not establish that a live bot is ready.

If your bot's order history disagrees with its dashboard, the bot repair page gives you a place to describe the expected and actual behaviour. Keep account identifiers and access details out of public comments.

MT5 error 10004: a requote is not a reason to retry forever

Arnold Holm — Fri, 23 Oct 2026 07:59:07 +0000

Your EA needs a stop condition after a requote. My policy example compiled with 0 errors; it sends no orders and proves no broker-side repair.

What the error means

A trader asked why a USDJPY buy request returned 10004 when the requested price and the server ask differed by only 0.001. That price difference alone does not establish the cause. The official MT5 server-return table names 10004 as TRADE_RETCODE_REQUOTE. Keep that server result alongside the exact request and quote instead of treating every rejected request as the same error.

A requote does not mean a position was opened. The table gives other codes for an order placed, a request completed and a request partly completed. The next decision depends on the actual result and account state. Do not let a generic retry branch treat those outcomes as interchangeable.

I separate receiving a requote from deciding whether an entry is still worth considering. A new quote can make an old signal stale or put the spread and price outside its limits. A loop that keeps resending until something succeeds can enter long after the original conditions disappeared.

The helper below only answers a local policy question: may this requote be reconsidered under the caller's stated limits? It rejects other return codes, an invalid signal, an exhausted attempt budget, an old quote, an invalid or excessive spread, and a price outside the allowed limit. A true result is permission to inspect the situation again. It is not permission to submit a trade blindly. The caller must supply current values and still check its order and position state.

Three code paths to check

The request and its server result were not preserved together.

Keep the requested price, bid, ask, execution mode, deviation, timestamps and full MqlTradeResult. A screenshot of one price difference cannot explain the whole request.

The retry branch ignores the original entry conditions.

Recheck the signal, quote age, spread and price limit before considering another request. Stop once the retry budget is used.

Several trade outcomes share one generic error branch.

Keep a requote separate from placed, completed and partly completed outcomes. Check orders and positions before any new submission to avoid duplicate intent.

A bounded local policy, with no order submission

I compiled RequotePolicy.mq5 with native MetaEditor on 23 October 2026. The compiler reported 0 errors and 0 warnings. The image renders that actual compiler result. Its OnStart only prints a label; it does not call this helper. I did not execute the script.

The limits are explicit inputs, not recommended trading settings. Quote age is supplied in milliseconds and spread in points. The caller is responsible for measuring them correctly and keeping attempt counts current. This example does not obtain quotes, change deviation or filling mode, wait for a new event, inspect positions, or retry an order.

bool MayReconsider(const uint retcode,const bool signal_valid,
                  const int attempts,const int max_attempts,
                  const long quote_age_ms,const long max_age_ms,
                  const double spread_points,const double max_spread_points,
                  const bool inside_price_limit)
{
 if(retcode!=TRADE_RETCODE_REQUOTE || !signal_valid) return false;
 if(max_attempts<=0 || attempts<0 || attempts>=max_attempts) return false;
 if(max_age_ms<0 || quote_age_ms<0 || quote_age_ms>max_age_ms) return false;
 if(!MathIsValidNumber(spread_points) || !MathIsValidNumber(max_spread_points)) return false;
 if(spread_points<0 || max_spread_points<0 || spread_points>max_spread_points) return false;
 return inside_price_limit;
}

Compile-only proof. No runtime branch tests, reproduced server 10004, broker request, automatic retry or successful trade.

Checks on your own source

Keep the failed request intact

Save the full request, result.retcode and result.comment, requested price, observed bid/ask, symbol execution mode and timestamp. Do not overwrite the first failure with the result of a later attempt.

Test refusal before any order path

On a separate demo test, cover a false signal, exhausted attempts, old quote, excessive spread and a price outside the limit. None may reach an order-send branch.

Your five-minute source check

Find the branch handling 10004. Trace its maximum attempts, its signal-validity check and the exact condition that prevents a new request. If one is missing, an automatic retry can outlive the original entry.

Common questions

Does increasing deviation always fix error 10004?

No universal repair follows from this code alone. Preserve the actual request, execution mode and server result before changing a setting.

Does a true helper result mean I should send an order?

No. It only passes this local policy. The caller still needs current inputs, order and position checks, and a separate submission decision.

Was a broker requote reproduced and fixed in this proof?

No. Only compilation is evidenced. The script was not executed and no broker request was made.

Sources

Original USDJPY requote question

Official MT5 trade server return codes

Original article

MQL5 error 4806: keep missing indicator data out of your signal

Arnold Holm — Thu, 22 Oct 2026 07:35:19 +0000

My guarded indicator reader compiled with 0 errors, but that proves no working signal on your account.

A trader reported repeated 4806 failures while reading indicator values across multiple currency pairs. The official runtime table names 4806 as requested indicator data not found. That describes missing data at the call. It does not identify one universal repair for every program.

I keep missing data out of the trading decision. For this small original example, the intended sample is one completed-bar value from buffer zero of an existing moving-average handle. The code first rejects an invalid handle or fewer than two calculated values. It then requests exactly one value starting at shift one. Only a complete copy with a finite, non-empty sample can update the caller's output.

The readiness check is useful but does not guarantee that the next call succeeds. The copy result is checked again. A failed read leaves the caller's output untouched. The caller still has to respect the false result and skip its decision. Treating that untouched old output as a new signal would defeat the whole guard.

These choices are specific to this example. A different indicator may expose a different buffer number, require a longer warm-up period or use different empty-value semantics. A multi-symbol program also needs to identify which handle and symbol failed. Keep a bounded retry on a later event rather than adding an endless loop that blocks the program. The compiled helper alone does not implement handle creation, retries or signal generation.

A handle exists before the requested values are ready.
Record the handle, calculated count, requested shift and count at the failure. A handle number alone is not evidence that a sample exists.

The requested buffer does not match the indicator.
Check the actual indicator interface. This example uses moving-average buffer zero. Do not apply that number blindly to a custom indicator.

A failed copy was turned into an ordinary number.
Check the returned copy count before reading the array. Keep a missing sample separate from a legitimate zero or a previous value.

A one-value reader that refuses an incomplete copy

bool TryClosedMA(const int handle,double &value)
{
 if(handle==INVALID_HANDLE || BarsCalculated(handle)<2) return false;
 double sample[1];
 ResetLastError();
 if(CopyBuffer(handle,0,1,1,sample)!=1) return false;
 if(!MathIsValidNumber(sample[0]) || sample[0]==EMPTY_VALUE) return false;
 value=sample[0];
 return true;
}

I compiled BufferReader.mq5 with native MetaEditor on 22 October 2026. It produced zero errors and zero warnings. Its OnStart only prints a label and never calls TryClosedMA. I did not run the script. The image below renders the actual compiler result.

This is a source-level example, not an observed cure for error 4806. There is no reproduced error-to-recovery sequence, indicator output, strategy run or broker request in this proof. Before using it, test the caller's false-result path and the chosen indicator's actual data behaviour on demo.

Compile-only proof. No reproduced runtime 4806, indicator readiness check, retry sequence, strategy validation or order submission.

Preserve the failing request
Record symbol, timeframe, indicator parameters, handle, buffer number, shift, count and the copy result. Reset the error before the call and capture it immediately after a failure.

Test the no-data branch
On demo, a missing sample must skip the trading decision. The previous output must not become a new signal merely because the read failed.

Your five-minute source check
Find the CopyBuffer call that failed. Compare its requested buffer, shift and count with the indicator interface, then find the branch that prevents use of an incomplete copy.

Does BarsCalculated alone remove error 4806?
No. The subsequent copy can still fail or return an incomplete sample. Check its result as well.

Did this proof reproduce and repair a runtime error?
No. It proves only that this original defensive reader compiles. A real indicator and caller still require runtime tests.

Sources: CopyBuffer, BarsCalculated, runtime error codes.

Original version with compiler proof.

Why can your $100,000 challenge dashboard turn green with no data?

Arnold Holm — Tue, 20 Oct 2026 21:04:07 +0000

Your $100,000 example account can show unknown against a $2,000 daily loss limit: 7 invented checks kept missing data separate from a clean recorded path.

Two recorded equity values can sit above a challenge loss floor while the recording between them is missing. A green badge is too strong a conclusion. In these checks, an empty recording and a NaN both returned unknown, while a recorded crossing stayed a crossing even when another value was missing.

This is a small Python check for a dashboard or exported journal. It does not determine whether a real account passed a firm's rules.

The problem is the label

Suppose the fixed floor is 98,000. The first and last recorded values are both 100,000. If the middle value is absent, the data does not tell us whether the path crossed the floor.

A developer might already handle that gap but still miss two other cases. An empty list can pass an all(...) check. A NaN can make a numeric comparison false without raising an exception. Both can quietly end up with a reassuring label.

There is also a precedence question. A recording of 100000 -> 97000 -> missing contains both a crossing and a gap. Returning only unknown throws away the crossing we actually observed.

I keep a recorded crossing visible even when the recording also has gaps.

Three states, with crossing checked first

The accepted data is deliberately small: a list of numbers or None, a fixed finite floor, and an inclusive boundary. A value equal to the floor counts as a crossing in this example. The function does not accept arbitrary strings or read an account. NaN means that a stored entry is not a valid number.

from math import isfinite

def status(values, floor=98_000):
    if any(v is not None and isfinite(v) and v <= floor for v in values):
        return "crossing recorded"
    if not values or any(v is None or not isfinite(v) for v in values):
        return "unknown"
    return "no crossing in recorded values"

cases = [
    ([100_000, 99_000, 100_000], "no crossing in recorded values"),
    ([100_000, 97_000, 100_000], "crossing recorded"),
    ([100_000, 98_000, 100_000], "crossing recorded"),
    ([100_000, None, 100_000], "unknown"),
    ([], "unknown"),
    ([100_000, float("nan"), 100_000], "unknown"),
    ([100_000, 97_000, None], "crossing recorded"),
]
for values, expected in cases:
    assert status(values) == expected, (values, expected)
print("7 synthetic checks passed")

The final label is intentionally narrow: no crossing in recorded values. It does not say that nothing happened between samples. Adding more samples does not by itself prove continuous coverage either.

What I would show beside the badge

A trader needs to know what the software saw. Beside the status, show the last recorded time, which recording period is covered, and whether there are known gaps. Keep the fixed-floor assumption visible. If a crossing exists, retain its recorded time and value even if collection later fails.

The $2,000 loss limit in this invented example is measured from a starting value of $100,000. That produces the fixed $98,000 floor. A reading of $97,000 is $1,000 below that floor. This is a deliberately chosen test case, with a made-up rule, rather than a result from a trading account.

For a real challenge, first map the firm's actual rule. Does it use balance or equity? Is the floor fixed or trailing? What happens at the daily reset, and which timezone defines it? Fees, open positions and the firm's own measurement feed can change the calculation. None of those rules is tested by this short program.

Try this before trusting the colour

Delete every value from a test export. Then replace one middle value with NaN. Finally put a known below-floor value before a missing value. Does the dashboard distinguish those three cases, or does it turn one of them green?

This is one small check for the broader question of challenge readiness. Seven invented cases test these labels and their precedence. They do not establish a profitable strategy, complete account history or a pass verdict.

For a starting point on the account rules themselves, use the free Challenge Pre-Check.

MQL array out of range: check 3 values before reading a buffer

Arnold Holm — Mon, 19 Oct 2026 15:59:44 +0000

MQL array out of range: check 3 values before reading a buffer

Your indicator cannot read a value that is absent from its array. My native MT5 run passed six array-read checks without executing an invalid read. I check the returned count and array size before reading an indicator value.

What the array error means

An array holds a sequence of values. Its size tells you how many elements exist. With three elements, the valid indices are zero, one and two. Three is the size, but it is already outside the array. A loop that includes the size as its final index can therefore reach a value that does not exist.

A forum author converting an MT4 indicator to MT5 reported an array error and posted code that copied indicator values and then read element zero. The posted code also attempted more buffer bindings than its declared buffer count. These are separate places to inspect. The discussion does not establish that a single guard repairs that whole indicator.

For a copied indicator value, keep the return count from CopyBuffer. Requesting one element is an intention. The return value tells you how many elements were actually copied, or reports failure. An empty or failed result must stay out of the array access. An allocated array alone does not establish that its old values belong to the latest successful request.

The helper below receives the actual array, the count from the current copy and the index you intend to read. It rejects a non-positive count, a negative index, an index at or beyond the copied count and an index at or beyond the physical array size. Only then does it read the element. Keep these inputs tied to the same operation. Passing a count from an earlier copy would change what this check means.

Three places to inspect

The copy result was ignored.

Save the return count from the current CopyBuffer call. Keep zero and negative results out of the read. Record the handle, buffer and requested shift separately so the failed request can be investigated.

The loop reached the size itself.

For a three-element ordinary array, the final valid index is two. Check the upper bound before entering the read. Also check a lower bound when an offset subtracts from the loop index.

The buffer setup was assumed to succeed.

Keep the declared buffer count, binding indices and SetIndexBuffer return values together. Read direction and which candle a position refers to need their own checks after the binding. The guard here checks bounds, not trading meaning.

The local bounds guard

bool SafeRead(const double &values[],int copied,int index,double &out)
{
   if(copied<=0 || index<0 || index>=copied || index>=ArraySize(values)) return false;
   out=values[index];
   return true;
}

Six fixed cases in native MT5

I compiled and ran my original read-only script in an isolated MT5 terminal on 19 October 2026. The empty-array input was blocked. A negative index was blocked. The last valid index in a three-value array returned 30. An index equal to the size was blocked. An index outside a shorter copied count was blocked even though the array itself was larger. A negative copy-result input was blocked.

All six comparisons passed. The runtime log and screenshot retain those outcomes. No invalid element was deliberately accessed. The value 30 is a fixed input used to check the helper, rather than a market price or trading result. The chart behind the text is terminal background.

This is a small boundary you can test before investigating the rest of an indicator. In your own program, preserve the original input and error line first. A bounds check should stop the unavailable read; it should not quietly turn missing data into an entry signal.

Check your own error line

Find the array access named by your Journal error. Log its requested index, actual array size and copy return count before that line.

Six fixed local inputs, zero orders and no real CopyBuffer call; no third-party indicator repaired, candle order established or live feed tested.

DEMO0: send the problem and try a free compiled demo first. 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.

Native runtime log: https://stratcorealpha.com/proof/fix/FIX-20-runtime.txt

Original page: https://stratcorealpha.com/fix/mql-array-out-of-range

Send your rule sheet or trading program for the free Challenge Pre-Check.

MT5 filling flags are not your order filling policy

Arnold Holm — Sun, 18 Oct 2026 13:38:13 +0000

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.

MT5 return code 10006: keep the result before retrying

Arnold Holm — Sat, 17 Oct 2026 14:00:29 +0000

Your bot can receive a result without a fill. My MT5 run passed 3 synthetic return-code checks and sent zero orders. I keep rejection, placement and completion separate before considering another request.

A trader asked how to check a failed Python order and send it again. The thread reported return code 10006. The journal did not give the trader a useful cause. The request included a market order, stop loss and take profit.

The useful next step is to retain the request and returned result together. An error number alone cannot tell you whether changing a price, stop distance or filling mode addresses this particular failure.

Before: one label hides three states

This reduced logging pattern loses the distinction a retry decision needs:

Print("order result received");

Receiving a result and filling a trade are different events. A log that collapses them leaves the next attempt without a clear starting state.

The official Python order_send reference returns a trade-result structure. Its request field contains the submitted request. The example expands both structures with _asdict(). Keep that detail rather than reducing the result to one short string.

After: preserve distinct local states

I used this small original classifier in a native MT5 script:

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 classifier takes a number and returns a label. It does not send an order or choose a retry. The unknown branch matters too. A new code must remain visible instead of falling through to a success label.

The native result

The script supplied three fixed inputs. The runtime receipt retained these outputs:

Synthetic input	Local classification
10006	REJECTED_REASON_UNKNOWN
10009	COMPLETED_RECONCILE_DEAL
10008	PLACED_NOT_FILLED

All three comparisons passed. The native run recorded orders_sent=0 and server_reject_reproduced=false. The EURUSD chart was the capture surface. It was not a trade in this test.

The result supports one narrow claim: the local classifier kept those three chosen values separate. It establishes no broker cause, server rejection or complete execution state machine.

Keep the receipt before choosing another attempt

For one real failed request, retain the original symbol, volume, order type, requested prices and timestamp. Keep the returned code, comment, order and deal fields beside it. If an external return code is present, retain that too. A local attempt identifier helps join later order and deal records without confusing a trading intent with a new submission.

Then compare the relevant order, deal and position state for the operation you requested. A placed order and a completed request need different handling. Even completion needs reconciliation with the corresponding account record.

The official OrderSend reference explains why a true function return alone does not establish a completed market trade. A retry loop should not turn missing information into a second entry.

Open one rejected request and compare its returned code, comment, order and deal fields with its original request and timestamp. If your log saved only a label, improve that receipt first. If the reason is missing, keep it unknown.

The original native proof and its boundaries are on the FIX-15 page.

If your first receipt loses these fields, check that logging change with one rejected, one placed and one completed example before enabling any automatic retry.

For a bounded source review, Free EA Code Check begins with readable code and one expected result.