fix(store + engine): closest-pane window queries + precompute_window annotation

[zzylol]

Summary

Two related changes — a store-side filter fix and an engine/adapter change — both addressing the original symptom (PromQL queries returning empty even though the store has data) and the user follow-up ("answer with a single closest window and annotate which one").

PromQL queries against sketch-aggregated metrics returned empty even though the precompute store demonstrably had data — worker logs Worker emitting 1 sketch outputs for group (1, ), runtime-info earliest_timestamp_per_aggregation_id populates, yet the engine reports No precomputed outputs found.

Part 1 — Overlap filter (commit a7ca91d)

MutableEpoch::range_query_into and SealedEpoch::range_query_into in simple_map_store/common.rs (and the on-disk parts variant in per_key.rs:query_disk_parts) used a "fully contained" filter:

if tr.0 < start || tr.0 > end || tr.1 > end {
    continue;  // pane must satisfy: start ≤ tr.0 ≤ tr.1 ≤ end
}

For tumbling windows of size W with a query range of size R, this matches at most floor(R / W) panes — and only when both query endpoints land exactly on the pane grid. PromQL queries don't align: quantile_over_time(...[1m]) with prometheus_scrape_interval=30 and a pane size of 30s, the query range [query_time - 60s, query_time] is offset from the 30s grid by the wall-clock fractional portion of query_time, so neither of the two panes that should match is fully contained — both have tr.0 < start (they straddle the lower boundary) or tr.1 > end (they straddle the upper boundary). Result: empty.

Fix: standard half-open interval overlap test. A window [tr.0, tr.1) overlaps the query range [start, end) when tr.1 > start && tr.0 < end. Skip iff neither (i.e. tr.1 <= start || tr.0 >= end).

Same change in three places that all share the same dead semantics:

• common.rs::MutableEpoch::range_query_into (columnar, used by current/in-flight epoch).
• common.rs::SealedEpoch::range_query_into (sorted-entries variant, used by older sealed epochs).
• per_key.rs::query_disk_parts (on-disk parts iteration — matches the in-memory contract).

The SealedEpoch variant kept its partition_point binary-search upper bound but was rewritten to bound by tr.0 < end instead of tr.0 < start — entries where tr.0 < start can now overlap (when tr.1 > start).

Part 2 — Closest-pane + annotation (commit 86aafbc)

After Part 1, the engine could merge 2-3 overlapping panes. That works for sum/count but is slightly imprecise for sketch summaries — the merged sketch covers more time than the query asked for — and the caller has no way to see which time range was actually consulted.

Per follow-up review feedback, for window queries the engine now picks a single closest pane and annotates the response with the actual [start_ms, end_ms) it used.

Pick the closest pane

In execute_and_merge_store_queries, after the store returns overlapping panes, compute the global "closest" pane (max tr.1, tie-break on max tr.0 — the latest pane that overlaps the request range). Then:

• Tumbling case: keep only that pane per series, run through the existing merge path (no-op for a single bucket but preserves accumulator-side cleanup).
• Sliding case: untouched — was already exact-match per key.

Thread window_used through QueryResult

InstantVector and RangeVector get a new window_used: Option<(u64, u64)> field, paired with QueryResult::with_window_used (chainable like with_accuracy).

execute_query_pipeline returns (elements, window_used). execute_context attaches the window onto the QueryResult. The schema-timeline dispatch path drops the per-segment window because a combined-result spans multiple agg_ids/windows; only the single-agg path surfaces it.

Annotate the Prometheus HTTP response

PrometheusResponse::with_precompute_window((start, end)) pushes a human-readable line onto the existing infos array:

precompute_window: [1777655280000, 1777655310000) ms (width 30000 ms)

Mirrors the with_accuracy pattern — no new top-level field on the wire, just an item in the existing infos. Grafana 11+ already renders these inline.

Verification (live end-to-end)

b3-delta agent (60s window, 30s tumbling panes), querying after 3+ window flushes have populated the store:

offset=-90s → value=19.493849507395904
              precompute_window: [1777655280000, 1777655310000) ms (width 30000 ms)
offset=-75s → value=19.493849507395904
              precompute_window: [1777655280000, 1777655310000) ms (width 30000 ms)
offset=-60s → value=19.493849507395904
              precompute_window: [1777655280000, 1777655310000) ms (width 30000 ms)
offset=-45s → value=19.493849507395904
              precompute_window: [1777655280000, 1777655310000) ms (width 30000 ms)
offset=-30s → value=19.493849507395904
              precompute_window: [1777655280000, 1777655310000) ms (width 30000 ms)

Same value and same precompute_window across the offsets — engine consistently picked the same closest pane ([17:08:00, 17:08:30)) and reported it. Pre-fix queries returned result: []. Pre-Part-2 the value would have been right but infos carried only the accuracy line; caller had to guess which range produced the value.

A query at now-30s or now-0s correctly empty when the most recent pane is younger than the query end — the agent hasn't flushed it yet (timing, not the filter, expected for [1m] queries with a 60s agent window + 30s pane that close 60-90s after the data they cover).

Test plan

• PromQL quantile_over_time(0.5, http_requests_total_latency_ms_quantile[1m]) returns non-empty at appropriate offsets.
• All four runtime range checks at now-120s, now-90s, now-60s return real values; now-30s, now-0s correctly empty due to data not yet emitted.
• infos array contains a precompute_window: [start, end) ms (width N ms) line for every non-empty result.
• Same query at adjacent offsets returns the same precompute_window (engine deterministically picks the same closest pane).

🤖 Generated with Claude Code

[zzylol]

Update — closest-pane + response annotation (per @user feedback)

Pushed an additional commit: 86aafbc fix(engine): pick closest pane for window queries + annotate response.

The previous overlap fix in this PR returned all overlapping panes and merged them, which works numerically for sum/count but is slightly imprecise for sketch summaries (the merged sketch spans more time than the query asked for) and gave the caller no visibility into the actual time range consulted.

This update changes that:

1. Single closest pane. In execute_and_merge_store_queries, after the store returns all overlapping panes, compute the latest pane (max tr.1, tie-break on max tr.0) and keep only that pane per series before running through the merge path. Sliding-window queries are unchanged (they were already exact-match).
2. window_used on QueryResult. New Option<(u64, u64)> field on InstantVector / RangeVector paired with chainable QueryResult::with_window_used. Mirrors the with_accuracy pattern.
3. Annotate the response. PrometheusResponse::with_precompute_window((start, end)) pushes one line onto the existing infos array:

precompute_window: [1777655280000, 1777655310000) ms (width 30000 ms)

No new top-level field on the wire; Grafana 11+ already renders infos inline.

Verification (live e2e)

Sweeping query offsets from -90s to -30s:

offset=-90s → value=19.493849507395904
              precompute_window: [1777655280000, 1777655310000) ms (width 30000 ms)
offset=-75s → value=19.493849507395904
              precompute_window: [1777655280000, 1777655310000) ms (width 30000 ms)
offset=-60s → value=19.493849507395904
              precompute_window: [1777655280000, 1777655310000) ms (width 30000 ms)
offset=-45s → value=19.493849507395904
              precompute_window: [1777655280000, 1777655310000) ms (width 30000 ms)
offset=-30s → value=19.493849507395904
              precompute_window: [1777655280000, 1777655310000) ms (width 30000 ms)

Same value and same precompute_window — engine consistently picked the same closest pane ([17:08:00, 17:08:30)) and reported it. Pre-update, infos only carried the accuracy line; the caller had to guess which range produced the value.