Workflow [PR], commit [b5bb249]

Summary: ✅

AI Review

Summary

This PR fixes a real exception path in InterpreterKillQueryQuery::getSelectResult by materializing ColumnConst columns before downstream typeid_cast calls to concrete column types. The change is surgical, addresses the reported failure mode, and is covered by a new regression test for KILL QUERY and KILL MUTATION test paths.

ClickHouse Rules

Final Verdict

• Status: ✅ Approve

A question - why were columns const?

The mechanism that produces `ColumnConst` in the query pipeline is:

1. When the Planner encounters a constant expression in the query tree, it wraps the value in `ColumnConst` via `ConstantValue::wrapToColumnConst` (in `src/Analyzer/ConstantValue.h`).
2. This `ColumnConst` is stored in an `ActionsDAG` COLUMN node via `ActionsDAG::addColumn`.
3. When `ExpressionActions::execute` processes the COLUMN node, it calls `cloneResized(num_rows)` on the column, which for `ColumnConst` returns another `ColumnConst` — preserving the const wrapping.
4. The output block thus contains `ColumnConst` columns.

The trigger in this case is the AST fuzzer (enabled in PR #98138). The fuzzer modifies the WHERE expression of `KILL QUERY`, and the modified expression gets embedded into the internal `SELECT query_id, user, query FROM system.processes WHERE <fuzzed_expr>`. The fuzzed expression can cause the query planner to produce a plan where one of the output columns becomes a constant (e.g., if the optimizer determines that a column has a known constant value after filtering, or if the fuzzed expression itself introduces constants in the projection path).

Unfortunately I don't have the exact fuzzed query that triggered this (logs were not downloadable from the CI report), but the fix is the standard ClickHouse approach — `materializeBlockInplace` converts all `ColumnConst` to their underlying concrete column types.

I investigated this extensively and I have to admit: I cannot determine the exact fuzzed expression that produced the const column.

What I verified does NOT produce const columns:

• `WHERE 1` (constant true) — `dumpColumnStructure` shows regular `ColumnString`
• `WHERE query_id = 'test'` (equality predicate) — still regular `ColumnString` in the plan (all ALIAS/INPUT nodes, no COLUMN nodes)
• `WHERE query_id = 'test' SETTINGS optimize_substitute_columns = 1` — same, because the optimization requires table constraints
• `WHERE user = currentUser()`, `WHERE user IN (SELECT 'default')` — all regular columns
• Any standard WHERE expression on system.processes — the columns remain INPUT/ALIAS in the projection ActionsDAG

What I found about the fuzzer: For `ASTKillQueryQuery`, the fuzzer falls through to the generic handler at line 3699 which just calls `fuzz(ast->children)`, fuzzing the WHERE expression recursively. It can modify literals, swap function names, wrap expressions in `toLowCardinality()`/`toNullable()`/`materialize()`, wrap in scalar subqueries, etc. — but I could not construct a scenario where any of these transformations cause the output columns of `SELECT query_id, user, query FROM system.processes WHERE ` to become `ColumnConst`.

The mechanism for ColumnConst in pipelines is well understood: ActionsDAG COLUMN nodes produce `ColumnConst` through `ExpressionActions::execute` → `cloneResized()`. But I couldn't find a planner pass that would replace an INPUT column (`query_id`, `user`, `query`) with a COLUMN (const) node in the projection for this kind of query.

It's possible the actual bad cast was not to/from `ColumnConst` but some other column wrapper (e.g., `ColumnLowCardinality` or `ColumnNullable` if the fuzzed expression triggered a type change). Unfortunately the CI report abbreviates the type names as "A" and "B".

The `materializeBlockInplace` fix handles all these cases (`ColumnConst`, `ColumnSparse`, and other special representations), so it's correct regardless of the exact trigger.

LLVM Coverage Report

PR changed lines: PR changed-lines coverage: 100.00% (4/4, 1 noise lines excluded)
Diff coverage report
Uncovered code