Repository navigation
Binary-query arms can't use a query_config with a query-time stage #858
Description
Problem
resolve_arm_leaf_context in asap-query-engine/src/engines/simple_engine/promql.rs returns None for any binary-query arm whose query_config has non-empty query_time_aggregations. So binary queries like sum by (job) (a) / sum by (job) (b) or sum by (job) (x) * 100 can't be answered locally when a leaf is served through a query-time stage (planned_subquery + stage), and they fall back to Prometheus.
#852 refuses MILP exact roll-ups for binary-query leaves for this reason. That means exact sum/count/min/max deployments can't be shared with a coarser leaf of a binary query.
Fix direction
Teach the binary-arm path to run the leaf's anchor, apply its query-time stage, and then combine the arms. Instant and range should go through the same path. Once it works, lift #852's refusal for binary leaves.
Activity
milindsrivastava1997 commentedon Oct 13, 2026
Another case for this: a workload that has the same query both standalone and as a binary arm (e.g.
sum by (job) (x)andsum by (job) (x) * 100). If the MILP rolls that query up from an exact deployment, the whole plan is refused (RollupUnsupported { reason: BinaryArm }), because the standalone query and the arm share one query_config. Once arms can run stages, that refusal can be lifted.