DanielLeens commented on issue #11884: URL: https://github.com/apache/seatunnel/issues/11884#issuecomment-5355733277
Thanks for writing this up so concretely. I checked the current `dev` path before replying, and the bug report matches the way stop mode is wired today: 1. `StopConfig.getStopOffset(...)` still resolves `latest()` immediately. 2. `IncrementalSplitAssigner` stores that result into the incremental split when the split is created. 3. `IncrementalSplit` keeps that `stopOffset` as split state. 4. `MySqlBinlogFetchTask` later stops the bounded binlog reader as soon as the current offset is at or after `split.getStopOffset()`. So for snapshot-taking startups, a `latest` stop offset captured before the snapshot can indeed become stale before the binlog phase begins, which is consistent with the data-loss window you described. PR #11885 looks like the right review boundary for this issue: - resolve the effective `latest` stop offset when the binlog phase actually starts; - keep `specific` / `timestamp` behavior unchanged; - prove the snapshot-window DML case with E2E coverage instead of only unit-level reasoning. The main thing I would still watch carefully in review is restore / state compatibility: `latest` should stay a dynamic runtime boundary, while fixed stop modes should keep their persisted split semantics unchanged. Since the implementation path is already open in #11885, I would keep the deeper code discussion on that PR and use this issue as the user-visible bug record. -- 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]
