replay_start silently relocates an out-of-range date and reports success

[stanzhang]

replay_start with a date outside the available replay depth relocates to the earliest date it can reach, and still returns success:

{"success": true, "replay_started": true, "date": "2020-12-08", "current_date": 1629665700}

date echoes what was requested; current_date is 2021-08-22. Nothing in the result says they differ, and TradingView shows a "data point unavailable, the chart was moved to the first point available for playback" toast that the API never surfaces.

Every read taken afterwards — data_get_ohlcv, data_get_study_values, the Pine graphics readers — is then correct for a date the caller did not ask for. For point-in-time work that is the one failure that invalidates the whole result, and it is reported as success.

Reproduce

replay_start on CME_MINI:NQ1! at 5, date 2020-12-08 → cursor lands on 2021-08-22.

Worth noting because I assumed otherwise at first: this is per symbol, not a global depth rule. The same 5-minute request on COINBASE:ETHUSD reaches 2020 and returns genuine bars.

Suggested fix

Compare and report. start() already reads currentDate back:

{"success": true, "replay_started": true, "requested_date": "2020-12-08",
 "current_date": "2021-08-22T20:55:00Z", "relocated": true,
 "hint": "2020-12-08 is outside replay depth for this symbol/timeframe"}

A relocated flag would be enough; callers doing point-in-time reads can fail closed on it. Throwing by default with an allow_relocation escape would also be defensible, since a silently different date is rarely what the caller wanted.

Related, same call

Changing timeframe while replay is running leaves the cursor from the previous timeframe and the new series comes back empty — replay_status reports is_replay_started: true with a stale current_date, and data_get_ohlcv throws chart_loading indefinitely until replay is stopped. Refusing a timeframe change during replay, or resetting the session when one happens, would save the diagnosis.