DanielLeens commented on issue #11260: URL: https://github.com/apache/seatunnel/issues/11260#issuecomment-4861294140
Thanks for writing this up with the code path already narrowed down. I checked the current restore flow, and this does look like a real bug in the multi-table CDC restore path. The key mismatch is exactly where you pointed: `IncrementalSource.restore()` only prunes deleted tables from `SnapshotPhaseState`, but the restored incremental split state can still retain the removed table in `IncrementalSplit.tableIds`. After that, `JdbcSourceFetchTaskContext.registerDatabaseHistory()` iterates those stale table IDs and tries to load schema for a table that is no longer part of the current job config, which explains the `Can't obtain schema for table ...` failure during reader startup. So this should stay open as a confirmed bug. I would suggest keeping the fix focused on two things: 1. prune removed tables from all restored incremental-state structures, not only `SnapshotPhaseState` 2. add a restore test that starts with a multi-table checkpoint/savepoint, removes one table from the config, and verifies the remaining table can resume cleanly Your proposed scope makes sense, especially around `tableIds`, `completedSnapshotSplitInfos`, `checkpointTables`, and `historyTableChanges`. If a restored incremental split becomes empty after pruning, dropping that split is also a reasonable direction. -- 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]
