SummaryExecutor: permanent self-exclusions + upstream composition gaps leave some PromQL shapes always on the legacy/archive path #436

Summary

Several PromQL query shapes can never be served from a summary/sketch via SummaryExecutor and permanently fall back to the legacy dispatch / archive path — some by this repo's own deliberate design, some because of gaps upstream in ASAPController. This issue consolidates them in one place since they share a root cause ("can't be answered via summary today") but are currently scattered across separate issues/comments.

This repo's own permanent self-exclusions

data_plane/src/query_engines/asap_query_engine/l4_lowering.rs's LoweringSkip enum documents two shapes lower_promql_to_l4node excludes before ever attempting to bind, by design — not bugs, not TODOs:

1. LoweringSkip::RateShape (l4_lowering.rs:69-78) — rate()/irate() queries. lower.rs's bind_recursive rewrites AggIntent::Rate → Increase before binding, which WOULD bind successfully to a valid SummaryAgg{Increase} tree, but summary_executor.rs has no rate-division logic (dividing by a coverage-clamped range), so comparing against it would produce a spurious mismatch. Must be excluded before ever calling into control_plane's binder.
2. LoweringSkip::NotRealized (l4_lowering.rs:88-98) — outer fold over an aggregate, e.g. topk(K, sum by(...)(rate(m[r]))). implement_tree_in_with only recurses through Aggregate nodes, so hitting the outer Sort/Limit wraps the WHOLE tree as one opaque Logical blob even though the inner aggregate would bind fine on its own.

Neither has a workaround today; both always fall back to the legacy SketchReducer/archive path.

Related, already-filed issues (not duplicated here, just linked for context)

• ASAPController#171 — composed exact→summary / summary→exact query shapes not supported in either direction.
• ASAPController#172 — nested approximate-over-approximate aggregation not supported.
• ASAPQuery-backend#432 — exact TopK (accuracy: Exact) has no warm-tier materialization, always falls to archive (partially blocked on ASAPController#151's missing exact_realization accumulator form for TopK).

Why this issue exists separately

None of the above already frame "why does this query never get served from summary" as one topic across both this repo's own permanent exclusions and the upstream composition gaps. Confirmed via gh issue list that #348 is a different, narrower topic (activating the exact→archive routing gate), not this.

Ask

Track this as the umbrella "queries that can't be summary-served" issue. Close (or don't) independently as upstream/local gaps are addressed — this issue is for visibility, not meant to gate other work.