[flink-cdc] Stabilize MySqlSyncDatabaseActionITCase.testSyncMultipleShards#8736
Merged
JingsongLi merged 1 commit intoJul 20, 2026
Conversation
…hards testSyncMultipleShards intermittently fails CI with java.util.concurrent.TimeoutException: testSyncMultipleShards() timed out after 120 seconds (for example, it failed the CI run of an unrelated PR apache#8735, whose changes are confined to paimon-common global btree index code and cannot reach Flink CDC). This is a flaky timeout, not a functional regression. Raise the per-method @timeout from 120s to 240s. Unlike its siblings this test does several sequential waitForResult phases, each preceded by a schema ALTER that forces the CDC source to re-snapshot the changed table, on top of Flink job startup and the initial MySQL snapshot/binlog switchover, so under a loaded CI runner it legitimately exceeds 120s even though the data volume is tiny. 240s is the value already used by the comparable heavy multi-table test in this class, testSyncManyTableWithLimitedMemory (the newly-added-table tests use 600s). Capture the JobClient returned by runActionWithDefaultEnv and thread it through the four waitForResult calls. Previously the test used the JobClient-less overload, in which checkJobNotTerminated is a no-op, so a dead CDC job was indistinguishable from a slow one and the test simply hung until the outer @timeout fired, yielding an opaque timeout with no diagnosis. With the client wired in, a terminated job now fails fast with a clear AssertionError. This matches the pattern already used by other tests in the same file. No production code changes; test-only. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
|
+1 |
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.
Purpose
MySqlSyncDatabaseActionITCase.testSyncMultipleShardsintermittently fails CI withjava.util.concurrent.TimeoutException: testSyncMultipleShards() timed out after 120 seconds(for example, it failed the CI run of an unrelated PR #8735, whose changes are confined topaimon-commonglobal btree index code and cannot reach Flink CDC). This is a flaky timeout, not a functional regression.Two things make the test prone to spurious timeouts.
First, the 120s per-method budget is tight for this test. Unlike its siblings it does several sequential
waitForResultphases, each preceded by a schemaALTERthat forces the CDC source to re-snapshot the changed table, on top of Flink job startup and the initial MySQL snapshot/binlog switchover. Under a loaded CI runner this legitimately exceeds 120s even though the data volume is tiny. This raises the timeout to 240s, the same value already used by the comparable heavy multi-table test in this class,testSyncManyTableWithLimitedMemory(the newly-added-table tests use 600s).Second, the test called the
JobClient-lesswaitForResultoverload, in whichcheckJobNotTerminated(...)is a no-op. If the CDC job ever dies, the test cannot tell a dead job from a slow one and simply hangs until the outer@Timeoutfires, producing an opaque timeout with no diagnosis. This captures theJobClientreturned byrunActionWithDefaultEnv(...)and threads it through the fourwaitForResultcalls, so a terminated job now fails fast with a clearAssertionErrorinstead of hanging. This matches the pattern already used by other tests in the same file (for example the newly-added-table tests).No production code changes; test-only.
Tests
MySqlSyncDatabaseActionITCase.testSyncMultipleShards(the modified test itself).