SEZ9 commented on issue #10203: URL: https://github.com/apache/seatunnel/issues/10203#issuecomment-6537844602
@ryanmeowy thanks for posting the revision, and for keeping the 23 Oct transition table and the 2a/2b paragraph in [6357660652](https://github.com/apache/seatunnel/issues/10203#issuecomment-6357660652) as the standing reference rather than re-stating them. From my side the completion-signal point is settled: the 2a/2b boundary is the split's own checkpointed watermark pair (`SnapshotSplit.isSnapshotReadFinished()`, both non-null), not membership in a finished-splits map; `finishedUnackedSplits` is rebuilt from that pair on restore (`IncrementalSourceReader.addSplits:152-153`), `restoreCompletedSnapshotSplit` uses the same predicate, and a mid-backfill checkpoint lands in 2a because the HIGH watermark exists only as the backfill's stop offset (`MySqlSnapshotSplitReadTask:154`). The "death inside the backfill" paragraph from your 24 Oct reply ([6379487210](https://github.com/apache/seatunnel/issues/10203#issuecomment-6379487210)) and the note you folded into the table comment on 29 Oct say the same thing, and §0 item 4 of the revision states it consistently ("the split's own watermark pair, not a finished-splits map, see contract 1"). Nothing is left open on that point — I consider it agreed against baseline `128994ca0` (re-checked at `3ac2d1cec`, per your note). One small suggestion only: where contract 1 restates the signal, a link back to 6357660652 would keep the table comment as the single source of truth so the two places cannot drift. No change needed if it already does that. <!-- streview-comment:2156 --> -- 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]
