Skip to content

Fix flaky 00965_send_logs_level_concurrent_queries - #110807

Open
tiandiwonder wants to merge 1 commit into
masterfrom
fix-flaky-00965-send-logs-level
Open

Fix flaky 00965_send_logs_level_concurrent_queries#110807
tiandiwonder wants to merge 1 commit into
masterfrom
fix-flaky-00965-send-logs-level

Conversation

@tiandiwonder

Copy link
Copy Markdown
Contributor

Problem

00965_send_logs_level_concurrent_queries is flaky on both master and pull requests (surfacing as a -OK/+Fail diff). It runs a query at send_logs_level=trace and asserts a verbose log line reached the client by matching <Trace>.

Root cause

A trivial SELECT * from numbers(...) is not guaranteed to emit a <Trace>-priority line — every LOG_TRACE on the query path is conditional. Under concurrency and randomized settings a run occasionally delivers no <Trace> line, so the check prints Fail.

Solution

executeQuery always logs the incoming query at <Debug> (logQuery), which is delivered at trace verbosity but filtered out at information verbosity. Match <Debug> as well as <Trace>, making the positive check deterministic and symmetric with the information-level negative check just below (which already asserts <Debug>/<Trace> are absent). The test still verifies the send_logs_level threshold: verbose logs are delivered at trace and filtered at information.

Verified against a running server: the patched test yields 10 OK, and an information-level query delivers no <Debug>/<Trace> lines.

Changelog category (leave one):

  • CI Fix or improvement (changelog entry is not required)

Documentation entry for user-facing changes

  • Documentation is written (mandatory for new features)

The test runs a query at `send_logs_level=trace` and asserts a verbose log line
was delivered to the client by matching `<Trace>`. That is flaky: a trivial
`SELECT * from numbers(...)` is not guaranteed to emit a `<Trace>`-priority line
(the `LOG_TRACE` calls on the query path are all conditional), so under
concurrency and randomized settings a run occasionally delivers no `<Trace>`
line and the check prints `Fail` (observed as a `-OK/+Fail` diff, flaky on both
`master` and pull requests).

`executeQuery` always logs the incoming query at `<Debug>` (`logQuery`), which is
delivered at trace verbosity but filtered out at information verbosity. Match
`<Debug>` as well as `<Trace>`, making the positive check deterministic while
keeping it symmetric with the information-level negative check just below (which
already asserts `<Debug>`/`<Trace>` are absent). The test still verifies the
`send_logs_level` threshold: verbose logs are delivered at `trace` and filtered
at `information`.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@clickhouse-gh

clickhouse-gh Bot commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

Workflow [PR], commit [396c385]

Summary:

job_name test_name status info comment
Stress test (amd_msan) FAIL
Received signal 8 (signal sent by pid 1374580110 from user 21925) (STID: 4141-584d) FAIL cidb

AI Review

Summary

This PR changes 00965_send_logs_level_concurrent_queries.sh so the positive case accepts either <Debug> or <Trace> instead of requiring a <Trace> line from SELECT * from numbers(...). I did not find a correctness gap in the current diff: send_logs_level=information still rejects both markers, so the concurrent test continues to verify the verbosity threshold, while tests/queries/0_stateless/00965_logs_level_bugfix.sh still covers actual trace-level delivery.

Final Verdict

✅ No new issues found in the current diff.

@clickhouse-gh clickhouse-gh Bot added the pr-ci label Jul 17, 2026
@tiandiwonder tiandiwonder added the can be tested Allows running workflows for external contributors label Jul 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

can be tested Allows running workflows for external contributors pr-ci

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant