{{ message }}
Fix flaky test 02770_async_buffer_ignore#107298
Open
groeneai wants to merge 1 commit into
Open
Conversation
The test asserted exact S3 read profile-event counts (S3ReadRequestsCount, ReadBufferFromS3Bytes, ReadCompressedBytes) for a narrow-range read. Those counts are non-deterministic across CI jobs: filesystem cache hits drop ReadBufferFromS3Bytes to ~830, parallel replicas raise the request count, and S3 read-ahead inflates the byte counts. Over 90 days this produced 212 failures across 12 unrelated PRs. Assert bounds instead: a narrow read of 2001 of 1000000 rows must not pull the whole part (~4 MB compressed per column), so S3ReadRequestsCount stays small and ReadCompressedBytes stays far below the full-column size. This still catches the over-read regression the test guards against while tolerating cache, read-ahead, and parallel-replica variance. Mirrors the approach in 03164_s3_settings_for_queries_and_merges. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
Author
Contributor
Author
|
cc @kssenii — could you review this? It is a test-only fix for the flaky |
alexey-milovidov
added
the
can be tested
Contributor
|
Workflow [PR], commit [6ce2bae] Summary: ❌
AI ReviewSummary
Final Verdict
|
Contributor
LLVM Coverage Report
Changed lines: No C/C++ source files changed — skipping uncovered code analysis. Newly covered by added/modified tests: 279 line(s), 45 function(s) across 113 file(s) · Details Top files
|
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):
...
Description
Fixes the flaky test
02770_async_buffer_ignore. Investigated at the request of @alexey-milovidov on #100391.The test asserted exact S3 read profile-event counts for a narrow-range read:
against the reference
4 66446 66446. Those exact counts are non-deterministic across CI jobs and the test cannot pin them away (it is alreadyno-random-settings). Over the last 90 days CIDB shows 212 failures across 12 unrelated PRs (only 1 on master), first seen 2026-03-26.Observed failure modes (vs reference
4 66446 66446):4 830 66446x174 (82%) - filesystem cache hit,ReadBufferFromS3Bytesdrops to ~8306 67909 67909x22 (10%) - parallel replicas4 7223260 66446x5 - S3 read-ahead reads most of the file4 66446 679xxx8 - async read-ahead pulls one extra compressed blockThe test verifies that a narrow read (2001 of 1000000 rows) does not pull the whole part. The fix keeps that intent but asserts bounds instead of exact values:
A narrow read uses few requests and decompresses ~66 KB; the full column is ~4 MB compressed, so an over-read regression still trips
ReadCompressedBytes < 1000000.ReadBufferFromS3Bytesis dropped because it is the unstable raw-transfer count (830 on cache hit, 7.2 MB on read-ahead). This mirrors03164_s3_settings_for_queries_and_merges, which asserts ratios for the same reason.Verified locally over MinIO
s3_disk: narrow read passes 15/15 with fresh DBs; warm re-reads that broke the old exact assertion (3 66031 66031,2 65616 65616) pass the new one; a full-column scan (4 MB) is still caught (1 0).This flake is unrelated to #100391: the query has no
ORDER BY, so the read-in-order path that PR changes is not exercised.