SEZ9 commented on PR #11382: URL: https://github.com/apache/seatunnel/pull/11382#issuecomment-5611818089
@DanielLeens thanks for re-pulling the raw body and reposting the continuation — that fills the gap, and I agree with your reading of the F2 mechanism now that I can see the whole argument. **On the direct answer to my question:** understood — there is no separate re-delivery path; the restarted subtask's own `READY_START` report re-triggers the existing `allTaskReady()` fan-in, which calls `notifyCompleted(latestCompletedCheckpoint)` and fans out the typed `CheckpointFinishedOperation` to every *current* subtask instance via `notifyCheckpointCompleted`. Both shapes (coordinator recreated with `alreadyStarted=true`, and coordinator surviving while one task restarts) route through the same `notifyCompleted(latestCompletedCheckpoint)` call and only differ in the trigger. That addresses the "I cannot find the re-delivery path" part of F2 and I'm fine treating it as answered, with two follow-ups so we can actually close it: 1. **F2/F4 — make the dependency explicit and tested.** Since recovery of `schemaChangeDrainReady` now rests entirely on `latestCompletedCheckpoint` surviving `cleanPendingCheckpoint`/`restoreCoordinator` and on the `allTaskReady()` replay, please add (a) a short comment on the guard and on the `notifyCompleted(latestCompletedCheckpoint)` call site stating that invariant, and (b) a test for the task-restart-only shape you describe: schema-change-before checkpoint completes → a single sink subtask restarts with a fresh `SchemaChangeDrainGuard` → `READY_START` → the replayed typed notification flips `schemaChangeDrainReady` and the next DDL is accepted. That is the gap F7 pointed at and it is what would let me move F2 and F4 to resolved rather than "explained". 2. **F1 interaction.** The replay is still asynchronous relative to the restarted sink resuming its data path, so the fail-fast race from F1 applies to this shape too: the fresh guard can see a DDL event before the replayed `CheckpointFinishedOperation` lands. Whatever resolution we settle on for F1 should cover the replayed notification as well, not only the first-time completion; please confirm the current fix handles that or say what still needs to change. **On the `1ee22aced02` correction:** your comment is cut off again on my end, right at `"isn't r` in the "One correction to ... push" paragraph — so this time it does seem to be more than a UI collapse, or the collapse hit both of us again. Could you repost just that correction, ideally as a separate shorter comment? I'd like to see exactly what claim about the "coordinator survives while one task restarts" scenario you're correcting before I sign off on the F2 conclusion, since the behavior of `1ee22aced02` in that shape is the piece I haven't been able to see yet. <!-- streview-comment:936 --> -- 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]
