submit_sweep never applies grid parameter values to the strategy instance

[leonardojgv]

Summary

submit_sweep's params grid does not appear to reach the strategy instance at execution
time. Every run in a swept grid produces bit-identical results, matching a plain
submit_backtest run of the same strategy with no override — regardless of what value the
grid actually requests for that run.

Setup

binance / BTC/USDT, window 2026-08-11 → 2026-08-13. Single-property strategy with a
settable JavaBean property cycleSeconds (annotated @StrategyProperty(name = "cycle.seconds"),
backed by setCycleSeconds):

import com.wualabs.qtsurfer.engine.core.instrument.Instrument;
import com.wualabs.qtsurfer.engine.core.state.StateStore;
import com.wualabs.qtsurfer.engine.indicators.helpers.WindowTimeRTIndicator.WindowTime;
import com.wualabs.qtsurfer.engine.indicators.helpers.group.InstrumentGroupRTIndicator;
import com.wualabs.qtsurfer.engine.strategy.AbstractTickerStrategy;
import com.wualabs.qtsurfer.engine.strategy.AbstractWindowListener;
import com.wualabs.qtsurfer.engine.strategy.StrategyProperty;

public class SimpleSweepTestStrategy extends AbstractTickerStrategy {

    @StrategyProperty(
        name = "cycle.seconds",
        description = "Number of seconds per full buy/sell cycle",
        defaultValue = "30"
    )
    private int cycleSeconds = 30;

    public void setCycleSeconds(int cycleSeconds) {
        this.cycleSeconds = cycleSeconds < 2 ? 2 : cycleSeconds;
    }

    @Override
    public boolean acceptInstrument(Instrument instrument) {
        return true;
    }

    @Override
    protected void setupIndicators(InstrumentGroupRTIndicator indicators) {
        indicators
            .addPrice()
            .window("price", WindowTime.s1, new TradeListener(this, indicators));
    }

    private class TradeListener extends AbstractWindowListener {

        TradeListener(AbstractTickerStrategy strategy, InstrumentGroupRTIndicator indicators) {
            super(strategy, indicators);
        }

        @Override
        public void onChange(StateStore store, double prev, double actual) {
            long count = store.inc("windowCount");
            long phase = (count - 1) % cycleSeconds;

            if (phase == 0 && !store.is("inPosition")) {
                emitBuy(actual);
                store.set("inPosition");
            } else if (phase == cycleSeconds - 1 && store.is("inPosition")) {
                emitSell(actual);
                store.unset("inPosition");
            }
        }
    }
}

Repro

1. submit_sweep with params: {"cycleSeconds": {"from": 25, "to": 35, "step": 1}} (grid
   sampler, objective sharpe) → 11 runs.
2. All 11 leaderboard rows come back identical: 4,454 trades, pnl -89122.4561, sharpe
   -8.1361, maxDD% 891.2246 — for every requested value from 25 through 35.
3. get_sweep_sensitivity marginals are completely flat for cycleSeconds (best = mean =
   worst at every single value), consistent with chore: bump sdk to 0.8.1, release 0.7.1 #2.

Isolating the cause

submit_backtest doesn't take a params override, so to test whether cycleSeconds genuinely
has no effect on this strategy, I bypassed the sweep grid mechanism entirely and edited the
class's field default directly, then ran three independent standalone backtests:

cycleSeconds (hardcoded field default)	trades
2	66,818
30 (unmodified default)	4,454
60	2,227

trades × cycleSeconds is constant across all three (133,620 / 133,620 / 133,636 — matching
within rounding at the window edge), exactly the 1 / cycleSeconds relationship the strategy's
cycle logic implies. So the property does control behavior whenever the field's compiled-in
value actually changes.

The sweep's 11 rows (25→35) are identical to the standalone run at the unmodified default
(30) — not to any of the values actually requested by the grid. That points at the grid
values never reaching the strategy instance before each run executes, rather than at the
strategy being insensitive to the parameter.

Expected

Each grid point in a sweep runs the strategy with that point's parameter value applied through
its JavaBean setter, matching a standalone backtest of the same strategy with the field
hardcoded to the same value.

Actual

Every run in the grid silently executes with the class's compiled-in default, ignoring the
requested value.

Environment

qtsurfer-mcp 0.10.3, API https://api.qtsurfer.net/v1

---

Note: while isolating this, the same sweep also showed the metrics-scale/consistency pattern
already tracked in #5 (large PnL, maxDD% > 100%) — added as a comment there instead of
duplicating it here, since it looks like the same underlying issue and this run gives a clean
trade-for-trade comparison against a standalone backtest.

[leonardojgv]

Verification: reproduces one layer below mcp-java, via sdk-ts directly

To narrow down whether this is a translation bug in mcp-java or something upstream, I reproduced the same case bypassing the MCP entirely — calling @qtsurfer/sdk's sweep() directly against the platform (https://api.qtsurfer.net/v1, prod) with a fixture that mirrors SimpleSweepTestStrategy:

@StrategyProperty(
    name = "cycle.seconds",
    description = "Number of seconds per full buy/sell cycle",
    defaultValue = "30"
)
private int cycleSeconds = 30;

public void setCycleSeconds(int cycleSeconds) {
    this.cycleSeconds = cycleSeconds < 2 ? 2 : cycleSeconds;
}

Baseline (plain backtest, binance BTC/USDT, 1h window, default cycleSeconds=30): 96 trades, pnlTotal=-0.043. Confirmed identical via both sdk-ts and qtsurfer-mcp for the same window/instrument — same worker, same numbers.

Sweep via sdk-ts directly (params: {"cycleSeconds": {"from": 25, "to": 35, "step": 5}}, bypassing the MCP entirely):

status: COMPLETED, leaderboardSize: 3, failReason: none
trades per row: [96, 96, 96]

Sweep via qtsurfer-mcp 0.10.3 (submit_sweep, identical strategy/grid/window):

#1 params={cycleSeconds=25.0}  trades=96  pnl=-1923.3283
#2 params={cycleSeconds=30.0}  trades=96  pnl=-1923.3283
#3 params={cycleSeconds=35.0}  trades=96  pnl=-1923.3283

Bit-identical results both ways, matching the original report.

Why this points upstream of the MCP

sdk-ts never goes through mcp-java — it's a separate, independently-tested client hitting the same executeSweep endpoint. Reproducing the exact same symptom through it rules out a request-building/translation bug local to the MCP layer. The bug has to be in the platform's sweep execution path.

One detail worth narrowing the search further

On the MCP run, each leaderboard row's params field correctly echoes the requested value (cycleSeconds=25.0, 30.0, 35.0 — not stuck on the default). So the per-trial vector does reach whatever assembles the leaderboard row / bookkeeping. What doesn't happen is that value reaching the actual strategy instance that executes the trial (setCycleSeconds(...) never getting called, or getting called with the wrong/default value). That suggests the disconnect is specifically between "vector recorded for this run" and "vector bound onto the worker's strategy instance before it executes" — not that the grid is discarded outright before dispatch.

Happy to share the fixture/repro script (TS, using sdk-ts's sweep()) if useful for triage.

[mrmx]

Confirmed still open and consistent with the upstream (sdk-ts) repro you added. This is a backend/platform issue more than an mcp-java translation layer one, since the sweep reaches the worker with the effective value it was compiled with.

No change since your sdk-ts repro of 18 Aug. This blocks meaningful use of submit_sweep entirely — without parameter injection the sweep just re-runs the same strategy N times. Should stay open until the platform applies per-vector values to the strategy instance.

[mrmx]

Retest 2026-08-20 (0.10.4) — still not fixed. Ran a 2-axis grid (emaFast 5/10/15 × emaSlow 20/30, 6 runs) and an 8-run LHS. All runs report distinct params in the leaderboard but bit-identical results (same pnl, trades, maxDD%, win%) across every run:

Grid: all 6 rows pnl -205865.7833 | trades 10770 | maxDD% 2058.66 | win% 0.0201
LHS: all 8 rows pnl -111909.8492 | trades 5859 | maxDD% 1119.10 | win% 0.0183

The grid values reach the leaderboard metadata but not the strategy instance — the sweep re-runs the same strategy N times. Confirmed at the platform level. This is the highest-impact blocker: it makes submit_sweep useless until fixed.

[mrmx]

Cleanest repro yet — using the exact SimpleSweepTestStrategy from this thread (forced buy/sell cycles every cycle.seconds), grid cycleSeconds: {values:[2,5,10,20]} on BTC/USDT 2026-06-01→03 (2026-08-20, qtsurfer-mcp 0.10.4):

run  cycleSeconds  trades   pnl          maxDD%
1    2             4604     -92968.3012   929.68
2    5             4604     -92968.3012   929.68
3    10            4604     -92968.3012   929.68
4    20            4604     -92968.3012   929.68

This strategy's whole purpose is that cycle.seconds changes the trade count (2s → far more cycles than 20s), so 4 identical 4604-trade results are conclusive: the grid value is not applied to the strategy instance. The params={cycleSeconds=N} shown in the leaderboard is only the sweep's own note of what it intended, not what ran.

Still the top blocker for submit_sweep being usable.

[mrmx]

Retest 2026-08-21 after engine update — not resolved. grid cycleSeconds {2,5,10,20} on the forced-cycle strategy still yields 4 bit-identical runs (trades 4604, pnl -9999.09) despite distinct params={cycleSeconds=N}. Grid value still never reaches the strategy instance.