DanielLeens commented on issue #12348: URL: https://github.com/apache/seatunnel/issues/12348#issuecomment-5714102369
Thank you for the complete restore trace. **Classification: A / Connector-V2 MySQL-CDC recovery state migration.** This is not just a missing initial snapshot. A configuration-added table must be introduced into the restored schema, snapshot, watermark, and incremental-split state as one compatible migration; otherwise the already restored reader can receive a binlog event for a table whose Debezium schema was never initialized. I checked the current recovery paths and the related work. `BaseChangeStreamTableSourceFactory` restores checkpoint table structures, while `IncrementalSplitAssigner.addSplits()` only restores watermarks for table IDs present in the recovered incremental split. The existing #11206 work addresses runtime wildcard discovery in a running job; it does not prove the distinct A -> checkpoint/savepoint -> add B to configuration -> restore contract described here, and its Build is not green. I found no open PR that covers this root cause. Before any implementation, please make that exact sequence a deterministic MySQL CDC E2E regression: restore A from its saved offset; verify B gets one snapshot at a defined watermark; then verify B binlog updates are accepted while A neither re-snapshots nor loses/replays its restored stream. The test must run for both checkpoint and savepoint recovery. A patch that only adds B to an `IncrementalSplit` is not sufficient unless it also establishes B schema/history and the snapshot-consistent watermark before incremental consumption. No help-wanted or assignment decision is made in this round. -- 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]
