[zzylol]

Why

#1173: when the same exact query runs every 10 s and every 15 s, the planner selects one SummaryTumblingWindowChain of 4 × 15000 ms, built at ingestion time, and both copies read it. The backend builds each tumbling window once, on the 15 s grid anchored at the epoch. The 10 s copy evaluates at multiples of 10 s, so at +10, +20, +40 and +50 s its newest window ends up to 10 s before the evaluation, and it answers from the wrong 60 s. On a deployment that keeps no raw data, that is a wrong answer for an exact query.

What

• Stage 2 rule. A tumbling-window chain is eligible for ingestion time only if every reader with a fixed interval has an interval that is a multiple of the chain's width. This applies with or without a declared phase.
• Otherwise the chain is pruned at ingestion time with the new reason PanesOffInterval, and stays a query-time candidate.
• Outputs. Stage 2's AllowedOutputs for the chain then lists only the readers whose interval it divides. Stage 3 enforces that list: today's engine through reach[q][c], and feat(plan-selection): group selection MILP over execution contexts as Stage 3's default search (#1095) #1144's group MILP through forbid_reach.

How

The fix is in ingestion_eligibility's chain branch (crates/physical-asap-optimization/src/lib.rs).

• Before: it checked only readers with a known phase (plan_pane_phase). A FixedInterval reader has no phase, so the loop continued, taking the reader to run on the chain's boundaries.
• After: each reader's QueryRecurrence::fixed_interval_ms() must be a multiple of tumbling_window_width_ms before the existing phase check runs.

This mirrors the whole-window branch below it, which already requires interval_ms.is_multiple_of(window_ms) (WindowOffEpochGrid). The module doc's ingestion rule now states both conditions.

Key code interfaces added / modified

None public. IngestionPruneReason is crate-private (pub(crate)); it gains one variant:

crates/physical-asap-optimization/src/lib.rs

/// Why a summary build cannot be materialized at ingestion time (S4). Stays.
pub(crate) enum IngestionPruneReason {
    // other variants unchanged
    /// A tumbling-window chain read at a fixed interval that its width does
    /// not divide (e.g. 15 s tumbling windows read every 10 s): built once
    /// each on the grid anchored at the epoch, its tumbling windows cannot
    /// end at every evaluation. Workload-dependent (not a bug); the chain
    /// stays a query-time candidate.
    PanesOffInterval, // new
}

Usage. A workload with sum by (job) (rate(m[1m])) twice, "fixed_interval": 10000 and "fixed_interval": 15000, over 6 series of m, planned with stage_pipeline --deployment-capabilities '{"raw_data_retained": false}':

• Stage 1 offers chains at several widths, including 10000, 15000 and 5000 ms.
• Stage 2 rejects the 15000 ms chain at ingestion time for the 10 s copy (PanesOffInterval) and the 10000 ms chain for the 15 s copy.
• Stage 3 now selects two ingestion-time chains, one per copy. The selected plan's materialized views:
  • 6 views of width_ms 10000 (end offsets 0 … 50000), read by the 10 s copy;
  • 4 views of width_ms 15000 (end offsets 0 … 45000), read by the 15 s copy.

Major algorithm changes

Stage 2 ingestion eligibility for tumbling-window chains

• Problem: see Why. For rate(m[1m]) every 10 s and every 15 s, Stage 2 emitted AllowedOutputs { candidate: C21 (15000 ms chain), outputs: [0, 1] }, and Stage 3 selected it for both outputs.
• Before / after: for each repeated reader of a chain of width w:
  1. (new) if the reader has a fixed interval i and i mod w ≠ 0, return PanesOffInterval;
  2. as before, a reader with a known phase must have that phase on the w-grid (PanesOffPhase), and a Scheduled reader with no common phase is rejected.
• Correctness: a chain built once per tumbling window on the epoch grid can answer evaluation time t only if t is a multiple of w. A reader at interval i with phase p evaluates at times ≡ p (mod i). All of them are multiples of w iff w divides i and w divides p. Step 1 checks the first condition; the existing phase check covers the second.
  • Tests: the regression test and the unit test listed under Verification.
• Complexity: one modulo per reader per chain candidate.
• Assumptions and limits:
  • EstimatedRate readers, which have no fixed interval, are still taken to run on the chain's boundaries, as before.
  • Range-evaluation steps are checked separately (PaneWidthOffRangeStep).
  • Stage 1 still offers widths that fit only some of a group's readers. Pass 2: offer only gcd tumbling-window widths; finer divisors are dominated #1171 narrows the offered widths to the gcd closure of the readers' grids.

Before this PR

A chain at ingestion time could serve a reader whose interval its width does not divide. Verified on main c83aa19 with plan_installable and runtime_install.rs's IngestionBuilds::Tumbling runtime: the 10 s copy differs from the query-time reference at 4 of 7 evaluations, for both rate and sum_over_time.

After this PR

Every evaluation of both copies equals the query-time reference. A chain built at ingestion time is shared only by readers whose intervals it divides. The planner keeps a 10 s chain and a 15 s chain for the example above. With raw_data_retained: false it could instead share one 5 s chain; it picks the cheaper of the two.

Verification

• Tests that fail before the fix and pass after:
  • cargo test -p asap-planner --test planner -- queries_at_two_intervals_read_chains_on_their_own_grids. Before the fix it fails at sum by (job) (rate(m[1m])), copy 0 (every 10000 ms) at 3610000.
  • cargo test -p asap-physical-asap-optimization --lib -- a_tumbling_window_chain_is_maintained_only_on_its_readers_intervals. Before the fix it fails with left: Ok(()) right: Err(PanesOffInterval).
• Related suites:
  • cargo test -p asap-physical-asap-optimization --lib: 31 passed.
  • cargo test -p asap-planner --test planner -- runtime_install::: 41 passed.
  • cargo fmt --check on both crates: clean.
• Plan snapshots: cargo test --release -p asap-devtools --test corpus_snapshots -- --ignored reports 22 snapshots (12 corpus, 10 sketch-plan) as differing. Each regenerated snapshot equals the committed one after JSON parsing with sorted keys, so no selected plan changed. The line diffs are key order only, e.g. tumbling_window_retention_ms and reduction placed differently in the committed files, which this PR does not touch. I did not rerun this test on main.

Follow-up

• Pass 2: offer only gcd tumbling-window widths; finer divisors are dominated #1171: offer only gcd tumbling-window widths, taking every reader of a group into account.