SEZ9 commented on issue #10203: URL: https://github.com/apache/seatunnel/issues/10203#issuecomment-6392285599
@ryanmeowy thanks, that clears up the recovery boundary for me. **Row 2b.** Agreed: the restored split reads as complete because the checkpointed `SnapshotSplitState` carries both `lowWatermark` and `highWatermark` and `SnapshotSplit.isSnapshotReadFinished()` sees them non-null, not because of membership in a finished-splits map. Low-only stays pending. **Death inside the backfill.** Also agreed. Since the HIGH watermark is only the backfill's stop offset until the emitter consumes the `[low ... high]` batch, a mid-backfill checkpoint persists both fields as null and restore re-runs the split as 2a; once a checkpoint carries both, it is 2b whether or not `onSplitFinished` ran. Please add a one-line note on rows 2a/2b that the split's own watermark pair, not any enumerator-side map, is the completion signal, so readers do not assume the finished-splits map is the source of truth. **Row 3.** Per-table wording is correct: `shouldEmit()` resolves `tableId` per record, `maxSplitHighWatermarkMap` is built per table from each `CompletedSnapshotSplitInfo` in `configureFilter()`, and `hasEnterPureBinlogPhase()` moves a table into `pureBinlogPhaseTables` once `position >= W_high`. Rewording row 3 that way also lines up with the invariant that a table joins the incremental filter only with its `W_high` from a completed checkpoint. Thanks as well for confirming the three contract items for the revision; I will look for them there. <!-- streview-comment:2006 --> -- 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]
