load_m1_window panics on a wide upper bound (to_ms = i64::MAX) instead of treating it as unbounded #23

New Issue

2026-06-04T22:58:17+02:00

Brummel commented

2026-06-04 22:58:17 +02:00

Surfaced while trying to load each asset's full history through the ingest boundary.

Reproduction

let server = Arc::new(DataServer::new(DEFAULT_DATA_PATH));
load_m1_window(&server, "EURUSD", 0, i64::MAX); // panics

thread 'main' panicked at data-server/src/records.rs:28:10:
unix_ms_to_year_month: invalid timestamp

Root cause

load_m1_window forwards its from_ms/to_ms straight to DataServer::stream_m1_windowed, which maps each bound through unix_ms_to_year_month (chrono) for coarse file-level filtering. i64::MAX ms overflows chrono::DateTime::from_timestamp_millis, whose .expect(...) then panics. The panic originates in data-server, but aura-ingest is the boundary that exposes it.

Why it bites

There is no way to express an open upper bound through load_m1_window today: the signature is (from: i64, to: i64), so 'everything up to the latest bar' forces a sentinel, and the natural sentinel (i64::MAX) crashes. stream_m1_windowed itself already takes Option<i64> (None = unbounded) -- the aura-side wrapper threw that away.

Direction (not prescriptive)

Either thread Option<i64> through load_m1_window (None = unbounded, matching the underlying API), or clamp a too-large bound to a sane ceiling at the boundary. RED-first per the bug-fix discipline. (Upstream data-server hardening of unix_ms_to_year_month is a separate, external concern.)

Workaround used in the probe: to_ms = 2_051_222_400_000 (2035-01-01).

Surfaced while trying to load each asset's *full* history through the ingest boundary. ## Reproduction ```rust let server = Arc::new(DataServer::new(DEFAULT_DATA_PATH)); load_m1_window(&server, "EURUSD", 0, i64::MAX); // panics ``` ``` thread 'main' panicked at data-server/src/records.rs:28:10: unix_ms_to_year_month: invalid timestamp ``` ## Root cause `load_m1_window` forwards its `from_ms`/`to_ms` straight to `DataServer::stream_m1_windowed`, which maps each bound through `unix_ms_to_year_month` (chrono) for coarse file-level filtering. `i64::MAX` ms overflows `chrono::DateTime::from_timestamp_millis`, whose `.expect(...)` then panics. The panic originates in data-server, but aura-ingest is the boundary that exposes it. ## Why it bites There is no way to express an *open* upper bound through `load_m1_window` today: the signature is `(from: i64, to: i64)`, so 'everything up to the latest bar' forces a sentinel, and the natural sentinel (`i64::MAX`) crashes. `stream_m1_windowed` itself already takes `Option<i64>` (None = unbounded) -- the aura-side wrapper threw that away. ## Direction (not prescriptive) Either thread `Option<i64>` through `load_m1_window` (None = unbounded, matching the underlying API), or clamp a too-large bound to a sane ceiling at the boundary. RED-first per the bug-fix discipline. (Upstream data-server hardening of `unix_ms_to_year_month` is a separate, external concern.) Workaround used in the probe: `to_ms = 2_051_222_400_000` (2035-01-01).

Brummel added the bug label 2026-06-04 22:58:17 +02:00

Brummel referenced this issue from a commit

2026-06-05 00:01:17 +02:00

test(aura-ingest): RED for unbounded M1 upper bound

Brummel referenced this issue from a commit

2026-06-05 00:01:17 +02:00

fix(aura-ingest): express unbounded M1 window bounds via Option<i64>

Brummel closed this issue

2026-06-05 00:01:17 +02:00

Sign in to join this conversation.