SEZ9 commented on issue #12565: URL: https://github.com/apache/seatunnel/issues/12565#issuecomment-6096823303
@WXPNG thanks for confirming that the analysis matches what you reproduced on your side — that's useful validation. Quick status so this thread stays accurate: the fix is tracked in #12567, and its current head `e18f31cfcf` does carry the three source-level changes we asked for (table-specific restored offsets flowing through reader state, `IncrementalSplit`, reassignment and the fetcher; the MySQL restore scenario with `exactly_once` and `incremental.parallelism = 2` covering both the pre-existing and the newly added table against the sink; and a test-visible hook in the fetcher test instead of reflection). So there is a single implementation path and no parallel fix is needed here. That said, this is not fixed in `dev` yet. #12567 is still open and merge-blocked because its GitHub `Build` check is `ACTION_REQUIRED` rather than a completed run — GitHub could not detect a workflow run for the fork head. Remaining asks on #12567: - Sync the branch with current `dev` (`53733a112c9e935c5d97f7f24be249caa43b4fd5` was the baseline for the original analysis). - Make sure Actions are enabled on the fork, then push a fresh head so the Build workflow actually runs. - Once CI has a result for that head, request another review on #12567. I'll keep this issue open until #12567 lands in `dev`. If you have a chance to run the restore scenario from that branch against your own reproduction, a short note here on whether the old-table change after the saved offset is now delivered would be a helpful extra data point. <!-- streview-comment:1652 --> -- 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]
