SEZ9 commented on PR #12152: URL: https://github.com/apache/seatunnel/pull/12152#issuecomment-6259022175
Thanks @CryoThrust for checking the annotations on fork run `37615433319` — agreed that "repeatedly failed to be acquired (5 attempts)" on all 11 jobs is a runner-acquisition failure, not a test result, so it says nothing either way about the F1/F2 changes. On F1/F2 for `de042f22b`: your mapping of `testCheckpointErrorReportRejectionStillReachesCancellationOffCallerThread`, `testCheckpointErrorReportCompletesFutureWhenExecutorRejects` and `testCheckpointErrorReportDoesNotRunOnCallerThread` to the rejection path and the post-release propagation check sounds right, but I have not been able to confirm it against the code in `CheckpointCoordinator.java` / `CheckpointCoordinatorTest.java` yet, so I am not marking either finding resolved on the strength of the description alone. Agreed that rejection by both pools is not covered by any of the three tests and stays the explicitly identified follow-up rather than something the 19 passing tests are claimed to cover. What I still need: 1. An actually executed CI run for `de042f22bf59bd2f039f04c06957b4b05010bc4c`. Since the fork's workflows are paused, the queued rerun may never start; once Actions are re-enabled on the fork, "Re-run failed jobs" is the smallest option, and a fresh push is a reasonable fallback if it keeps sitting in the queue. 2. If any job then fails with a real test failure, please paste the job and test name here and I'll help classify it. No other code-side blockers from me. <!-- streview-comment:1878 --> -- 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]
