Skip to content

feat(sdk): run candle strategies, a data type on backtest and sweep requests - #11

Merged
mrmx merged 1 commit into
mainfrom
feat/data-source-type
Oct 25, 2026
Merged

mrmx merged 1 commit into
mainfrom
feat/data-source-type

Conversation

@mrmx

@mrmx mrmx commented Oct 25, 2026

Copy link
Copy Markdown
Contributor

What

The Java SDK could not run a strategy that reads candles. Both workflows fixed the data type to ticker, so a kline strategy over a klines dataset always failed at preparation:

This strategy reads kline data, but the run was submitted against ticker data. Run it against kline data, or use a strategy written for ticker data.

The TypeScript and Python SDKs already take a data type, and the MCP server (which sits on this SDK) had no way to ask for a kline run for the same reason.

Change

  • BacktestRequest and SweepRequest get type (DataSourceType; TICKER by default, KLINE for candles). Builders: .type(DataSourceType.KLINE). Every stage uses it: preparation, execution, polling, cancellation, and the sweep result, sensitivity and curve reads.
  • A run is addressed by its exchange, its type and its id, so the reads that took only an exchange and an id get overloads with a type: getBacktestResult(exchangeId, type, jobId), getSweepRunEquityCurve(exchangeId, type, ...) and getBoundedSweepRunEquityCurve(exchangeId, type, ...), on QTSurfer and on AuthenticatedClient. The forms without a type keep reading the ticker route.
  • The record constructors that predate type still work and build ticker runs. A null type means TICKER.
  • docs/backtesting.md shows how to ask for a kline run; changelog entry under [Unreleased].

Tests

  • DataSourceTypeRequestTest: the default, the given type, the older constructors and a null type.
  • A kline backtest prepares, executes, polls and reads on the kline route and never on the ticker one (Mockito); readResult addresses a run by its type; a kline sweep uses the kline route on every call (local HTTP server); getBacktestResult of a kline run hits /backtest/user/kline/execute/... through both QTSurfer and the session authenticate(...) returns.
  • mvn verify passes with the new tests (2 skipped, as before).

Checked live

The built classes against the live API (OpenAPI 0.128.47), on a ready klines dataset with a kline QTScript strategy:

  • a kline backtest completes; the same strategy as a ticker run still ends Failed with the platform's reason, now a QTSExecutionError;
  • a run is readable by its type (Completed) and not found on the ticker route (404);
  • a kline sweep over the dataset completes with its rows.

Not in this PR

No version bump or release. The MCP server takes the type in a following change, once this is released.

…equests

Every run the Java SDK started was prepared, executed and read as ticker data: the type was a constant in both workflows. A strategy that reads candles, run over a klines dataset, therefore always failed at preparation with 'This strategy reads kline data, but the run was submitted against ticker data'. The TypeScript and Python SDKs already take a data type.

BacktestRequest and SweepRequest get a type (DataSourceType, ticker by default, kline for candles) that every stage uses: preparation, execution, polling, cancellation and the sweep reads. A run is addressed by its exchange, its type and its id, so the reads that take only an exchange and an id (getBacktestResult, getSweepRunEquityCurve, getBoundedSweepRunEquityCurve) get overloads with a type; the forms without one keep reading the ticker route. The record constructors that predate the type still work.
@mrmx
mrmx temporarily deployed to Preproduction October 25, 2026 16:28 — with GitHub Actions Inactive
@mrmx
mrmx marked this pull request as ready for review October 25, 2026 16:53
@mrmx
mrmx merged commit ad613fe into main Oct 25, 2026
6 checks passed
@mrmx
mrmx deleted the feat/data-source-type branch October 25, 2026 16:55

This branch was previously deployed

1 inactive deployment
Preproduction — 206a9760 Deployed Oct 25, 2026 by mrmx via integration #115
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant