When the original query context has parallel replicas enabled,
fuzzed queries inherit these settings and can trigger
"Initiator received more initial requests than there are replicas"
exception in `ParallelReplicasReadingCoordinator`. This is not a
real bug but a consequence of running fuzzed queries in the same
server context. Disable parallel replicas for fuzzed queries by
setting `max_parallel_replicas` to 1.

Co-Authored-By: Claude Opus 4.6 <[email protected]>

…nce in filterResultForNotMatchedRows

The BuzzHouse test failed with a `chassert` in `Context::setCurrentTransaction`
because the fuzz context inherits `implicit_transaction = true` but is not
registered as a session or query context.

The AST fuzzer (arm_asan) crashed with a segfault in
`ActionsDAG::evaluatePartialResult` because `tryFindInOutputs` returned nullptr
for fuzzed queries where the filter column name was not found in the DAG outputs.

Co-Authored-By: Claude Opus 4.6 <[email protected]>

When `ast_fuzzer_any_query` is enabled, the fuzzer can produce INSERT
queries that create a pushing pipeline (expecting input data). The code
only handled the pulling case, falling through to
`CompletedPipelineExecutor` which throws a fatal exception
"Pipeline for CompletedPipelineExecutor must be completed" and
terminates the server.

Handle all three pipeline states: skip pushing (no data to provide),
complete pulling with `NullOutputFormat`, and execute completed directly.

https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=98138&sha=ce2d2fd4afda542d07976faa413573f209ba27e8&name_0=PR&name_1=Stress%20test%20%28amd_release%29

Co-Authored-By: Claude Opus 4.6 <[email protected]>

The smoke check runs `00001_select_1` and
`00234_disjunctive_equality_chains_optimization` before the actual
stress tests to validate that randomized settings don't break basic
functionality. The server-side AST fuzzer produces expected errors
in stderr from fuzzed queries, which the test runner interprets as
test failures.

Pass `ast_fuzzer_runs=0` as a client option for the smoke check
only, so the actual stress test still runs with the fuzzer enabled.

#98138

Co-Authored-By: Claude Opus 4.6 <[email protected]>

The AST fuzzer created a context that was both its own session and query
context. When the fuzzed query triggered an implicit transaction,
`InterpreterTransactionControlQuery::executeBegin` set the transaction
on the session context via `initCurrentTransaction`, then tried to set
it again on the query context via `setCurrentTransaction` — but they
were the same object, hitting the assertion
`!merge_tree_transaction || !txn`.

Fix by creating a separate session context object so that query and
session contexts are distinct, matching the normal execution flow.

https://s3.amazonaws.com/clickhouse-test-reports/json.html?REF=master&sha=7a972da94a98935d46b6f2d6c98ef79117e082c4&name_0=MasterCI&name_1=Stress%20test%20%28amd_debug%29

Co-Authored-By: Claude Opus 4.6 <[email protected]>

`makeQueryContext`/`makeSessionContext` only change the
`query_context`/`session_context` pointers — they do not clear
direct Context members copied by `Context::createCopy`:
`merge_tree_all_ranges_callback`, `merge_tree_read_task_callback`,
and `client_info.collaborate_with_initiator`.

When the initiator sends a query to replicas with
`ast_fuzzer_runs > 0`, each replica runs the fuzzer after the
original query completes. The fuzz context inherits the TCPHandler
callbacks and the follower flag, so the fuzzed query acts as a
parallel replicas follower and sends a second
`InitialAllRangesAnnouncement` through the inherited callback to
the already-finished coordinator — causing "Duplicate announcement
received" or "Initiator received more initial requests than there
are replicas".

Disable `allow_experimental_parallel_reading_from_replicas` in the
fuzz context so that `canUseTaskBasedParallelReplicas` returns
false, preventing both initiator and follower parallel replicas
behavior regardless of inherited callbacks.

Co-Authored-By: Claude Opus 4.6 <[email protected]>

…ring stack unwinding

Move fuzz context creation outside the try block so that contexts are not
destroyed during stack unwinding. When a fuzzed query throws an exception,
`MergeTreeTransactionHolder` destructor calls `rollbackTransaction` (noexcept),
which calls `getCurrentExceptionCode` using bare `throw;`. This only works
inside a catch handler, not during stack unwinding, causing `std::terminate`.

By moving contexts outside try, they are destroyed after the catch block,
and we explicitly reset transactions in the catch block to prevent the
destructor from attempting a rollback.

Co-Authored-By: Claude Opus 4.6 <[email protected]>

Skip `logExceptionBeforeStart` for internal queries in `executeQueryImpl`
to avoid polluting server error logs. Internal query errors are always
propagated back to the caller which handles them appropriately.

In the AST fuzzer catch blocks, log only the exception code instead of
the full exception message. This prevents fuzzed query failures (like
"Logical error: Input initializer is not set" from `input()` usage)
from triggering the stress test log scanner that checks for patterns
like "Logical error" in server logs.

Co-Authored-By: Claude Opus 4.6 <[email protected]>

… exceptions

Add a warning to `system.warnings` when `ast_fuzzer_runs` is enabled,
similar to the existing `THREAD_FUZZER_IS_ENABLED` warning.

Change log level of AST fuzzer exception messages from LOG_ERROR/LOG_TRACE
to LOG_DEBUG.

Co-Authored-By: Claude Opus 4.6 <[email protected]>

…uction

Co-Authored-By: Claude Opus 4.6 <[email protected]>

Co-Authored-By: Claude Opus 4.6 <[email protected]>

The `Exception` destructor automatically logs all `LOGICAL_ERROR`
exceptions at ERROR level via `ForcedCriticalErrorsLogger` unless
`markAsLogged` has been called. This caused "Logical error: Input
initializer is not set" to appear in server logs despite all other
logging suppression, triggering stress test failure detection.

Use the same `try { throw; } catch (Exception & e) { e.markAsLogged(); }`
pattern as `tryLogCurrentExceptionImpl` in all three fuzzer catch blocks.

Co-Authored-By: Claude Opus 4.6 <[email protected]>

The AST fuzzer creates a copy of the original query context, which
inherits the `input_blocks_reader` callback from the TCP connection.
When the fuzzer generates queries using `input()`, `StorageInput::read`
sees the callback and assumes it's a legitimate TCP INSERT with input
data, then tries to call `initializeInput` which triggers a
LOGICAL_ERROR ("Input initializer is not set") or tries to read from the
same input pipe twice ("Trying to read from input() twice").

Reset both input callbacks on the fuzzed context so that `input()` in
fuzzed queries doesn't attempt to use callbacks from the original query.

Co-Authored-By: Claude Opus 4.6 <[email protected]>

…House/ClickHouse into enable-ast-fuzzer-stress-buzzhouse

The AST fuzzer creates a copy of the original query context for each
fuzzed query via `Context::createCopy`. This copies the
`table_function_results` cache, which contains `StorageInput` objects
from the original query with `was_pipe_used = true`. When a fuzzed
query happens to use `input()` with the same AST structure, it finds
the stale cached `StorageInput` and hits the "Trying to read from
input() twice" logical error in `ReadFromInput::initializePipeline`.

Fix by clearing `table_function_results` on the fuzz context after
creation, so stale table function storage objects are not reused.

https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=98138&sha=48fbefe2e46da9d88ad55ab43fd40d6380d7c1c5&name_0=PR

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

The hung check queries `system.processes` and runs `00001_select_1` to detect
deadlocks. With `ast_fuzzer_runs=5` and `ast_fuzzer_any_query=true` active in
the server profile, these diagnostic queries were also being fuzzed, causing
`CANNOT_SCHEDULE_TASK` errors and timeouts that consumed the entire 600-second
budget.

Pass `ast_fuzzer_runs=0` as a client option to the hung check command, matching
what the smoke check and stress test runs already do.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>