Problem
prepend_metric_name (asap-query-engine/src/engines/simple_engine/mod.rs) runs unconditionally for every topk result, gated only on statistic_to_compute == Statistic::Topk — never on whether the wrapped expression should drop the metric name.
Real Prometheus semantics: sum_over_time/rate/sum/etc. set DropName: true on their output, and topk forwards that flag through. So topk(5, data) (bare vector selector) correctly keeps __name__, but topk(5, sum_over_time(data[5m])) should drop it — ASAPQuery keeps it in both cases. There's no DropName-equivalent concept anywhere in the codebase.
Expected behavior
For a series data{instance="i-1",job="worker"}:
topk(5, data) → output labels: {__name__="data", instance="i-1", job="worker"} (bare vector selector keeps the name)topk(5, sum_over_time(data[5m])) → output labels: {instance="i-1", job="worker"} (sum_over_time drops the name; topk forwards that)
Same for count_over_time (also drops the name) — every temporal function currently supported under topk (#699) drops it, so today's output is wrong for both.
Evidence
Confirmed live via the promql-compliance differential suite (aggregations case, PR #706): every topk(k, sum_over_time/count_over_time(...)) result diffs against Prometheus with metric or timestamp differs — extra __name__="data" that shouldn't be there, once the separate label-alignment bug (fixed in #706) was no longer masking it.
Scope note
Distinct from #631 (closed, fixed by #644) — that was topk(...) as a binary-expr arm breaking joins. #644's own summary says "standalone Topk output formatting remains unchanged" — this issue is exactly that standalone case.
Related in spirit to #531's tracking list (capability-matching/planner-engine inconsistencies), though this one is a query-engine formatting bug, not a matching bug.
Problem
prepend_metric_name(asap-query-engine/src/engines/simple_engine/mod.rs) runs unconditionally for every topk result, gated only onstatistic_to_compute == Statistic::Topk— never on whether the wrapped expression should drop the metric name.Real Prometheus semantics:
sum_over_time/rate/sum/etc. setDropName: trueon their output, andtopkforwards that flag through. Sotopk(5, data)(bare vector selector) correctly keeps__name__, buttopk(5, sum_over_time(data[5m]))should drop it — ASAPQuery keeps it in both cases. There's noDropName-equivalent concept anywhere in the codebase.Expected behavior
For a series
data{instance="i-1",job="worker"}:topk(5, data)→ output labels:{__name__="data", instance="i-1", job="worker"}(bare vector selector keeps the name)topk(5, sum_over_time(data[5m]))→ output labels:{instance="i-1", job="worker"}(sum_over_timedrops the name; topk forwards that)Same for
count_over_time(also drops the name) — every temporal function currently supported under topk (#699) drops it, so today's output is wrong for both.Evidence
Confirmed live via the
promql-compliancedifferential suite (aggregationscase, PR #706): everytopk(k, sum_over_time/count_over_time(...))result diffs against Prometheus withmetric or timestamp differs— extra__name__="data"that shouldn't be there, once the separate label-alignment bug (fixed in #706) was no longer masking it.Scope note
Distinct from #631 (closed, fixed by #644) — that was
topk(...)as a binary-expr arm breaking joins. #644's own summary says "standalone Topk output formatting remains unchanged" — this issue is exactly that standalone case.Related in spirit to #531's tracking list (capability-matching/planner-engine inconsistencies), though this one is a query-engine formatting bug, not a matching bug.