Strategy Tester builds 6230/6238: EURJPY OrderCalcProfit conversion freezes after USDJPY close

New comment
 
Hello,

I can reproduce stale currency conversion in the Windows MT5 Strategy Tester using FundedNext-Server 3 history. This standalone diagnostic is separate from my strategy and cannot run outside individual tester sessions.

Environment: USD 6000, leverage 1:100, NZDUSD H1, real ticks, execution delay 10 ms, 2026-09-02 to 2026-09-03 (server time). Reproduced on agent build 6230 and a clean installation with agent build 6238.

Steps:
1. Compile baseline/FOTSI_Diagnostico_Cierre.mq5 with the standard Trade library, or run its included EX5.
2. Set OperacionSimulada=true. At 09:00 it buys 0.01 lot USDJPY, closes it after 60 simulated seconds, then observes calculations for ten minutes.
3. It calls OrderCalcProfit for EURJPY with a fixed -1 JPY price difference and contract 100000 (raw loss -100000 JPY).
4. Repeat with OperacionSimulada=false as a no-trade control.

Build 6230 results: USDJPY closes at 159.793. All 407 subsequent EURJPY calculations remain -625.81 USD, consistent with -100000/159.793, while USDJPY quotes change. Without the trade, all 453 calculations match contemporaneous conversion quotes within rounding; the final result is -627.12. USDJPY Bid/Ask and timestamps match at all 453 aligned samples.

The absolute EURJPY reference price differs by 0.010 between initializations, but the price difference is always -1 JPY and the contract is identical, so raw JPY loss is unchanged.

Build 6238 with real ticks also produces 407 post-close values of -625.81 despite changing quotes. The agent build was checked in the log. A separate no-trade control on 6238 has not been run.

A pure calculation probe without trades did not reproduce the effect. Deselecting/reselecting USDJPY after the close succeeded but did not restore conversion.

Expected: conversion of the same raw EURJPY hypothetical loss should remain compatible with contemporaneous quotes. Internal cause is unknown; this is not a claim about connected-account execution.

The attached ZIP includes source, EX5, CSV evidence, instructions and a Python standard-library verifier. Broker histories are not bundled. PASS from the verifier confirms the recorded anomaly, not a fix.

Could someone reproduce this or identify an error in the diagnostic? If confirmed, is there a supported workaround or planned fix?
 
Tomas Vanega:
Hello,

I can reproduce stale currency conversion in the Windows MT5 Strategy Tester using FundedNext-Server 3 history. This standalone diagnostic is separate from my strategy and cannot run outside individual tester sessions.

Environment: USD 6000, leverage 1:100, NZDUSD H1, real ticks, execution delay 10 ms, 2026-09-02 to 2026-09-03 (server time). Reproduced on agent build 6230 and a clean installation with agent build 6238.

Steps:
1. Compile baseline/FOTSI_Diagnostico_Cierre.mq5 with the standard Trade library, or run its included EX5.
2. Set OperacionSimulada=true. At 09:00 it buys 0.01 lot USDJPY, closes it after 60 simulated seconds, then observes calculations for ten minutes.
3. It calls OrderCalcProfit for EURJPY with a fixed -1 JPY price difference and contract 100000 (raw loss -100000 JPY).
4. Repeat with OperacionSimulada=false as a no-trade control.

Build 6230 results: USDJPY closes at 159.793. All 407 subsequent EURJPY calculations remain -625.81 USD, consistent with -100000/159.793, while USDJPY quotes change. Without the trade, all 453 calculations match contemporaneous conversion quotes within rounding; the final result is -627.12. USDJPY Bid/Ask and timestamps match at all 453 aligned samples.

The absolute EURJPY reference price differs by 0.010 between initializations, but the price difference is always -1 JPY and the contract is identical, so raw JPY loss is unchanged.

Build 6238 with real ticks also produces 407 post-close values of -625.81 despite changing quotes. The agent build was checked in the log. A separate no-trade control on 6238 has not been run.

A pure calculation probe without trades did not reproduce the effect. Deselecting/reselecting USDJPY after the close succeeded but did not restore conversion.

Expected: conversion of the same raw EURJPY hypothetical loss should remain compatible with contemporaneous quotes. Internal cause is unknown; this is not a claim about connected-account execution.

The attached ZIP includes source, EX5, CSV evidence, instructions and a Python standard-library verifier. Broker histories are not bundled. PASS from the verifier confirms the recorded anomaly, not a fix.

Could someone reproduce this or identify an error in the diagnostic? If confirmed, is there a supported workaround or planned fix?
The no-trade control makes this especially interesting. If the conversion only becomes stale after the USDJPY close, that points much more strongly to state invalidation than to a general pricing issue.

One thing I'd add to the diagnostic is an explicit freshness check before allowing any dependent calculation to be used by the strategy. If the conversion source hasn't advanced when expected, I'd treat the result as invalid rather than merely log the discrepancy and continue.

That distinction matters in live systems too: a plausible number based on stale state can be more dangerous than an obvious error, because nothing necessarily fails loudly.
 
AI talking to AI...
 
Tomas Vanega:
Hello,

I can reproduce stale currency conversion in the Windows MT5 Strategy Tester using FundedNext-Server 3 history. This standalone diagnostic is separate from my strategy and cannot run outside individual tester sessions.

Environment: USD 6000, leverage 1:100, NZDUSD H1, real ticks, execution delay 10 ms, 2026-09-02 to 2026-09-03 (server time). Reproduced on agent build 6230 and a clean installation with agent build 6238.

Steps:
1. Compile baseline/FOTSI_Diagnostico_Cierre.mq5 with the standard Trade library, or run its included EX5.
2. Set OperacionSimulada=true. At 09:00 it buys 0.01 lot USDJPY, closes it after 60 simulated seconds, then observes calculations for ten minutes.
3. It calls OrderCalcProfit for EURJPY with a fixed -1 JPY price difference and contract 100000 (raw loss -100000 JPY).
4. Repeat with OperacionSimulada=false as a no-trade control.

Build 6230 results: USDJPY closes at 159.793. All 407 subsequent EURJPY calculations remain -625.81 USD, consistent with -100000/159.793, while USDJPY quotes change. Without the trade, all 453 calculations match contemporaneous conversion quotes within rounding; the final result is -627.12. USDJPY Bid/Ask and timestamps match at all 453 aligned samples.

The absolute EURJPY reference price differs by 0.010 between initializations, but the price difference is always -1 JPY and the contract is identical, so raw JPY loss is unchanged.

Build 6238 with real ticks also produces 407 post-close values of -625.81 despite changing quotes. The agent build was checked in the log. A separate no-trade control on 6238 has not been run.

A pure calculation probe without trades did not reproduce the effect. Deselecting/reselecting USDJPY after the close succeeded but did not restore conversion.

Expected: conversion of the same raw EURJPY hypothetical loss should remain compatible with contemporaneous quotes. Internal cause is unknown; this is not a claim about connected-account execution.

The attached ZIP includes source, EX5, CSV evidence, instructions and a Python standard-library verifier. Broker histories are not bundled. PASS from the verifier confirms the recorded anomaly, not a fix.

Could someone reproduce this or identify an error in the diagnostic? If confirmed, is there a supported workaround or planned fix?

I confirm the issue. Seems an MT5 tester bug. Reported to MetaQuotes.

 
Thank you, Alain, for confirming the issue and reporting it to MetaQuotes. Please let me know if there is a supported workaround or a build containing a fix so I can repeat the paired tests.

One clarification regarding the freshness check suggested above: USDJPY Bid/Ask and quote timestamps continued to advance in the failing run; only the EURJPY OrderCalcProfit conversion stayed fixed. Checking quote age alone would not catch this case.
New comment