LuciferYang opened a new issue, #9653: URL: https://github.com/apache/paimon/issues/9653
### Search before asking - [x] I searched in the [issues](https://github.com/apache/paimon/issues) and found nothing similar. ### Paimon version master, `475be566f` (2.1-SNAPSHOT). ### Compute Engine Flink, `paimon-flink-common` integration tests. ### Minimal reproduce step `AppendTableSavepointTagFailoverITCase.testRegionFailoverPreservesSavepointTag` fails intermittently in CI: ``` [ERROR] org.apache.paimon.flink.AppendTableSavepointTagFailoverITCase.testRegionFailoverPreservesSavepointTag Time elapsed: 0.837 s <<< ERROR! java.util.concurrent.ExecutionException: org.apache.flink.runtime.checkpoint.CheckpointException: Checkpoint triggering task Source: region-source (2/2) of job 361a330eeeffd33ab4ec1f2b89cc227c is not being executed at the moment. Aborting checkpoint. Failure reason: Not all required tasks are currently running. at org.apache.paimon.flink.AppendTableSavepointTagFailoverITCase.testRegionFailoverPreservesSavepointTag(AppendTableSavepointTagFailoverITCase.java:262) ``` Two runs from today, on unrelated pull requests that touch neither Flink nor checkpointing: - https://github.com/apache/paimon/actions/runs/33950240085/job/101263510564 (a `paimon-common` bitmap file index change) - https://github.com/apache/paimon/actions/runs/33951866816/job/101268061352 (a `paimon-common` cast rule change) The test injects a region failover, waits, and then triggers a second savepoint: ```java // Wait until the job has recovered and resumed committing after the region failover. waitUntilRecoveredAndCommitting(table); client.triggerSavepoint(getTempDirPath("savepoint2_" + tableName), SavepointFormatType.DEFAULT) .get(60, TimeUnit.SECONDS); ``` and the wait is defined as "a snapshot newer than the one we saw before": ```java private void waitUntilRecoveredAndCommitting(FileStoreTable table) throws Exception { Long baseline = table.snapshotManager().latestSnapshotId(); long base = baseline == null ? 0L : baseline; long deadline = System.currentTimeMillis() + WAIT_TIMEOUT_MILLIS; while (System.currentTimeMillis() < deadline) { Long latest = table.snapshotManager().latestSnapshotId(); if (latest != null && latest > base) { return; } Thread.sleep(200); } ... ``` ### What doesn't meet your expectations? A new snapshot is not the same condition as "every task is running again", which is what `triggerSavepoint` requires. A commit that was already in flight when the failover started can bump the snapshot id and satisfy the wait while the failed region is still being redeployed, and the savepoint then aborts with the message above. The 0.837 s elapsed time says the savepoint failed almost immediately rather than timing out, which is consistent with that. ### Anything else? Two ways to make it deterministic, whichever fits the suite better: wait on the job's own state (all vertices `RUNNING` via the cluster client) before triggering, or retry `triggerSavepoint` while it fails with a `CheckpointException` whose reason is that not all tasks are running, up to the existing timeout. The test was added in #9309. I have not tried to reproduce it locally; the evidence is the two CI runs above, which failed at the same line with the same reason. ### Are you willing to submit a PR? - [x] I'm willing to submit a PR! -- 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]
