Found while scoping #608. Today, a range query's lookback for a Sliding aggregation is always the aggregation's configured window_size_ms, regardless of what duration the PromQL selector actually says.
Current behavior
create_store_query_plan (mod.rs:432-436, instant path) computes the window as [end - window_size_ms, end] using the aggregation's configured window_size_ms — not whatever duration was parsed from the selector. finish_range_context's lookback (widen_query_window, promql.rs) derives from that same instant window's width, so it's window_size_ms too, transitively. The selector's own stated duration (the [Ns] text) isn't read anywhere in promql.rs's query-timing logic.
Concretely: with window_size_ms=5000, slide_interval_ms=1000, sum_over_time(cpu_load[10s]) and sum_over_time(cpu_load[5s]) produce identical results against this aggregation — the 10s is silently discarded in favor of the aggregation's real 5s window.
This was confirmed not to be a problem for #608's fix specifically (single-bucket lookup is correct and complete given this constraint), but it's a real, separate correctness/usability gap: a user writing [10s] reasonably expects 10 seconds of lookback, not silent substitution.
What removing the restriction would require
Given the store only ever holds one pre-merged, window_size_ms-wide bucket per grid position (worker.rs::merge_panes_for_window fully merges before storing — confirmed while investigating #608, no raw sub-window panes are ever stored), honoring a lookback wider than window_size_ms means merging multiple non-overlapping buckets, spaced window_size_ms apart (not the slide grid) -- e.g. for window_size_ms=5000 and a desired 10s lookback, sum the bucket ending at t with the bucket ending at t - 5000.
This is a genuinely different composition than both single_window (#608, one bucket) and scan_window (Tumbling, sum every grid position) — a third mode: sum every window_size_ms-th bucket within the requested lookback, skipping the ones in between (which overlap and would double-count).
Options worth considering
- Implement the above (support arbitrary lookback via non-overlapping multi-bucket merge).
- Or, if that's not wanted: validate the selector duration against the aggregation's configured
window_size_ms and error/warn on mismatch, instead of silently substituting -- cheaper, but doesn't add the capability, just makes today's limitation explicit.
Scope
Related: #557, #608.
Found while scoping #608. Today, a range query's lookback for a Sliding aggregation is always the aggregation's configured
window_size_ms, regardless of what duration the PromQL selector actually says.Current behavior
create_store_query_plan(mod.rs:432-436, instant path) computes the window as[end - window_size_ms, end]using the aggregation's configuredwindow_size_ms— not whatever duration was parsed from the selector.finish_range_context's lookback (widen_query_window,promql.rs) derives from that same instant window's width, so it'swindow_size_mstoo, transitively. The selector's own stated duration (the[Ns]text) isn't read anywhere inpromql.rs's query-timing logic.Concretely: with
window_size_ms=5000,slide_interval_ms=1000,sum_over_time(cpu_load[10s])andsum_over_time(cpu_load[5s])produce identical results against this aggregation — the10sis silently discarded in favor of the aggregation's real 5s window.This was confirmed not to be a problem for #608's fix specifically (single-bucket lookup is correct and complete given this constraint), but it's a real, separate correctness/usability gap: a user writing
[10s]reasonably expects 10 seconds of lookback, not silent substitution.What removing the restriction would require
Given the store only ever holds one pre-merged,
window_size_ms-wide bucket per grid position (worker.rs::merge_panes_for_windowfully merges before storing — confirmed while investigating #608, no raw sub-window panes are ever stored), honoring a lookback wider thanwindow_size_msmeans merging multiple non-overlapping buckets, spacedwindow_size_msapart (not the slide grid) -- e.g. forwindow_size_ms=5000and a desired10slookback, sum the bucket ending attwith the bucket ending att - 5000.This is a genuinely different composition than both
single_window(#608, one bucket) andscan_window(Tumbling, sum every grid position) — a third mode: sum everywindow_size_ms-th bucket within the requested lookback, skipping the ones in between (which overlap and would double-count).Options worth considering
window_size_msand error/warn on mismatch, instead of silently substituting -- cheaper, but doesn't add the capability, just makes today's limitation explicit.Scope
asap-query-engine/src/engines/simple_engine/promql.rs--create_store_query_plan,finish_range_context.execute_range_query_pipeline/single_window(mod.rs), alongside the existing Sliding (Range queries over Sliding-window aggregations use overlap-scan fetch, not exact-window fetch #608) and Tumbling paths.Related: #557, #608.