planner/optimizer — `get_statistics_to_compute` (`promql_utilities/src/query_logics/parsing.rs:71,81,84`) calls `panic!` on any matched-but-unrecognized statistic/function name. This is called from `aqe_extractor.rs::extract_requirements`, whose own doc comment (`aqe_extractor.rs:64-65`) says unsupported queries are "skipped with a warning."
In practice: any dashboard query that matches a pattern but uses a statistic outside the current enum crashes the whole `optimizer_cli` run instead of skipping that one leaf query.
Needs a decision before fixing: is silent-skip actually safe for every caller of `get_statistics_to_compute`, or are there callers that rely on the panic as a hard invariant check? Once decided, either change the panic to a `Result`/skip-with-warning, or update the `aqe_extractor.rs` doc comment to match reality.
Found during code review of PR #407.
planner/optimizer — `get_statistics_to_compute` (`promql_utilities/src/query_logics/parsing.rs:71,81,84`) calls `panic!` on any matched-but-unrecognized statistic/function name. This is called from `aqe_extractor.rs::extract_requirements`, whose own doc comment (`aqe_extractor.rs:64-65`) says unsupported queries are "skipped with a warning."
In practice: any dashboard query that matches a pattern but uses a statistic outside the current enum crashes the whole `optimizer_cli` run instead of skipping that one leaf query.
Needs a decision before fixing: is silent-skip actually safe for every caller of `get_statistics_to_compute`, or are there callers that rely on the panic as a hard invariant check? Once decided, either change the panic to a `Result`/skip-with-warning, or update the `aqe_extractor.rs` doc comment to match reality.
Found during code review of PR #407.