wombatu-kun opened a new pull request, #9907: URL: https://github.com/apache/paimon/pull/9907
### Purpose Closes #9653. `AppendTableSavepointTagFailoverITCase.testRegionFailoverPreservesSavepointTag` fails intermittently in CI on pull requests that touch neither Flink nor checkpointing. After injecting a region failover, the test waited for `latestSnapshotId()` to advance past a baseline before triggering a second savepoint. That is not the condition `triggerSavepoint` needs, which is that every task is `RUNNING` again. Commits on the coordinator-commit path are asynchronous: `CommittingWriteOperatorCoordinator.notifyCheckpointComplete` hands `committer.commit(...)` to a single-threaded executor via `runInEventLoop`, and the table runs with `commit.force-create-snapshot = true` and a 200 ms checkpoint interval. So a commit for a checkpoint that had already completed before the failover can land after the baseline read, satisfy the wait while the failed region is still inside its restart delay, and the savepoint is then rejected up front with `CheckpointFailureReason.NOT_ALL_REQUIRED_TASKS_RUNNING`. In the reported CI runs the whole test method took 0.837 s, which is consistent with a pre-flight rejection rather than a timeout. The fix waits for a snapshot whose commit identifier is past the aborted savepoint's checkpoint id. Commit identifiers are Flink checkpoint ids (`StoreCommitter.combine` builds `new ManifestCommittable(checkpointId, watermark)`, and the coordinator uses the same committer), so a commit that was in flight before the failover carries an identifier at or below the savepoint's and cannot satisfy it, while a commit past it can only come from a checkpoint that every task acknowledged. The same file already relies on this relation in `FailOnFirstPostRecoveryCommitCallback`. The change also asserts that the injected failure actually fired. That is not cosmetic: the existing `assertThatThrownBy` accepts any `CheckpointException`, so a savepoint rejected for an unrelated reason would have satisfied it without any failover happening, and the new wait would then be handed the `-1` sentinel and become vacuous. No Flink internals, REST client or reflection are involved, so the fix behaves identically under the `flink1` and `flink2` profiles. ### Tests Test-only change to `AppendTableSavepointTagFailoverITCase`. The flake was reproduced deterministically rather than waited for: raising the fixed restart delay to 10 s and removing the wait makes the second savepoint always land on a still-restarting region, which fails with exactly the reported error and passes with the new wait in place. The committed code runs green on the full class under both `flink1` (Flink 1.20.1, JDK 8) and `flink2` (Flink 2.2.0, JDK 11), and `testRegionFailoverPreservesSavepointTag` passed 20 consecutive runs on `flink1` and 8 on `flink2`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
