PromQL/SQL spatial aggregations rely on implicit time defaults that diverge across query languages

[milindsrivastava1997]

Summary

PromQL spatial aggregation (sum by (cpu) (metric), no range vector) and SQL spatial-style queries (no explicit time range) both mean "aggregate over the last scrape/ingestion interval," but that default is applied inconsistently per query language:

• PromQL: implicit, handled via QueryPatternType::OnlySpatial branches.
• SQL: implicit, handled via QueryType::Spatial branches with its own substitution logic.
• Elastic: always requires an explicit time range, but the window derived from it doesn't reliably match the requested duration (fix(planner): Elastic DSL window size falls back to t_repeat_ms instead of actual query duration #485).
• do_merge on QueryExecutionContext is set from the enum variant rather than computed from the resolved time range, so its correctness depends on the enum classification being right rather than on any explicit, checkable relationship between range and window size.

Why it matters

There's no single point where "what time range did this query actually use" is explicit and observable — it's reconstructed differently by each planner from different inputs (enum variant, scrape interval, ingestion interval). This makes the actual queried window hard to test directly and easy to get subtly wrong per language (#485 is one concrete consequence, on the Elastic path).

Evidence

• asap-planner-rs/src/planner/window.rs:51 — spatial window size branch
• asap-planner-rs/src/planner/cleanup.rs:26 — spatial lookback branch
• asap-planner-rs/src/planner/promql.rs, asap-planner-rs/src/planner/sql.rs:168 — per-language implicit-default handling
• do_merge set from QueryPatternType rather than derived, across asap-query-engine/src/engines/simple_engine/*