SEZ9 commented on issue #12441: URL: https://github.com/apache/seatunnel/issues/12441#issuecomment-5902801924
@Rangsh — agreed, and thanks for consolidating. Closing #12493 in favor of #12511 makes sense, since Vivek1106-04's change already carries the unlocked drain, the `CHECKPOINT_COORDINATOR_SHUTDOWN` mapping for a cut-short drain, and the SubPlan `jobMaster.isNeedRestore()` re-check. Since you offered to help on #12511, two things would be useful, both tied to the two bugs recorded above: 1. Re-run `CheckpointCoordinatorTest#testTryTriggerNotBlockedBySavepointDrain` against #12511 (red base `c3f06f9a82c119e427df0fb1f440bae583148f62`) and confirm it still goes red → green there, so the part-1 proof carries over from #12493. 2. Independently reproduce the SubPlan race: `SavePointTest#testSavePointButJobGoingToFail` failing with the unlocked drain but without the re-check and passing with it, and `SavePointTest#testSavePointFailureDuringPipelineRestoreWaitEndsTheJob` red on `dev`. A second look at the 4 s / 5 s savepoint outcomes vs. the 3 s restore wait is what I'd most like verified. @Vivek1106-04 — on bug 2, could you confirm here (or point to the relevant part of https://github.com/apache/seatunnel/pull/12493#issuecomment-5862502658) which of `CHECKPOINT_COORDINATOR_RESET`, `PIPELINE_END`, `CHECKPOINT_COORDINATOR_COMPLETED`, and the `handleCoordinatorError` reason are mapped to `CHECKPOINT_COORDINATOR_SHUTDOWN`, and which, if any, should still surface as a real savepoint failure? That's the remaining piece I'd like nailed down for the cut-short-drain behavior in #12511. <!-- streview-comment:1414 --> -- 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]
