Problem
Query-serving timestamp alignment in simple_engine silently floor-aligns the requested end_timestamp down to a grid boundary and logs only a warn! — the client never sees that the answer is actually as of an earlier timestamp than requested.
Existing case: align_end_timestamp_promql (asap-query-engine/src/engines/simple_engine/promql.rs:44-56) floor-aligns to data_ingestion_interval_ms. Bounded staleness: up to one scrape interval.
New case (introduced by #557): sliding-window store lookups need a second floor-align, down to the aggregation's own slide_interval_ms grid (worker buckets are epoch-anchored on that grid, per precompute_engine/window_manager.rs). Bounded staleness: up to one slide_interval_ms, which can be much larger than the scrape interval — e.g. a 60s slide on a 10s scrape means a query can silently be answered with data up to ~50s staler than requested, with only a debug/warn log to show for it.
Problem
Query-serving timestamp alignment in
simple_enginesilently floor-aligns the requestedend_timestampdown to a grid boundary and logs only awarn!— the client never sees that the answer is actually as of an earlier timestamp than requested.Existing case:
align_end_timestamp_promql(asap-query-engine/src/engines/simple_engine/promql.rs:44-56) floor-aligns todata_ingestion_interval_ms. Bounded staleness: up to one scrape interval.New case (introduced by #557): sliding-window store lookups need a second floor-align, down to the aggregation's own
slide_interval_msgrid (worker buckets are epoch-anchored on that grid, perprecompute_engine/window_manager.rs). Bounded staleness: up to oneslide_interval_ms, which can be much larger than the scrape interval — e.g. a 60s slide on a 10s scrape means a query can silently be answered with data up to ~50s staler than requested, with only a debug/warn log to show for it.