mirror of
https://github.com/hanzoai/datastore.git
synced 2026-09-26 13:55:07 +00:00
Groene AI
dfb634ffdf
Three sibling integration tests (mongodb, postgresql, mysql) have the same
flaky pattern that was already fixed for SQLite in commit a768cf39a3
("Fix flaky test_sqlite_kill_query/test_cancel_query under MSan"):
The test_cancel_query (or test_cancel_infinite_query /
test_cancel_query_during_generation) calls wait_for_log_line() for a log
line that the preceding test_kill_query also produces ("Generate a chunk",
"Get data from database", etc.). With the default look_behind_lines=10000,
the wait matches a STALE log entry from the preceding test immediately, so
the test proceeds before the new clickhouse client query has actually
entered the receive loop. Under sanitizers (3-5x slower) the gap between
the stale match and the new client actually starting is wider, so SIGINT
is sent before the client has connected. The client exits without sending
a Cancel packet, the server never logs the expected exception, and
wait_for_log_line("DB::Exception: Received 'Cancel' packet from the
client") times out at 30s.
Fix mirrors the SQLite precedent:
- Add look_behind_lines=0 to the "wait for query to start" calls so tail
-F only sees new log lines (forces the test to wait for the new query
to actually start producing data before sending SIGINT).
- Simplify the cancel-acknowledgment regex from
"DB::Exception: Received 'Cancel' packet from the client" to
"Received 'Cancel' packet from the client" so it also matches the
LOG_INFO path ("returning partial result") in TCPHandler.cpp.
The SQLite fix dropped master failures of test_sqlite_kill_query to zero
in 79 days; expect the same outcome here. The 30-day CIDB data for
test_mongodb_kill_query/test.py::test_cancel_query shows 2 master hits
(both 2026-05-12) on `Integration tests (amd_asan_ubsan, db disk, old
analyzer, 1/6)` plus 6 unrelated PR hits, all with the same stack trace
ending at wait_for_log_line:5354.
Session: cron:clickhouse-ci-task-worker:20260517-121500