DanielLeens commented on PR #11503: URL: https://github.com/apache/seatunnel/pull/11503#issuecomment-5364325392
CI re-check follow-up (2026-08-20): my 2026-08-17 review said the Build check was still QUEUED and I hadn't seen a result. It has since run and completed — worth reporting. **What happened**: the branch picked up a new `dev` merge today (`9cbeac086672`, "Merge branch 'dev' into codex/fix-10461-restore-cdc-schema", 2026-08-20T06:00Z), producing a fresh Build run: https://github.com/nielifeng/seatunnel/actions/runs/32337830395 (conclusion: failure, 3 failing jobs). Root-caused each: - `jdbc-connectors-it-ddl (8, ubuntu-latest)` — never reached the test phase. `./mvnw` hit `429 Too Many Requests` fetching `maven-wrapper-3.1.0.jar` from `repo.maven.apache.org`. Pure Maven Central rate-limit flake, unrelated to this PR. - `all-connectors-it-7 (8, ubuntu-latest)` — `PostgresCDCIT.testPostgresCdcSnapshotOnlyAndCommittedOffsetStartupModes` failed with an `awaitility` `ConditionTimeoutException` (`expected: <1> but was: <0>` within 2 minutes). - `paimon-connector-it (11, ubuntu-latest)` — `PaimonSinkCDCIT.testSinkWithIncompatibleSchema` failed the same way: `awaitility` timed out waiting for the SeaTunnel container to finish, reporting a lingering `st-multi-table-sink-writer-1` thread pool worker still parked in `getTask()`. The last two are worth flagging precisely because this PR touches `IncrementalSourceReader`/Debezium restore logic (which Postgres CDC shares) and `PaimonSinkWriter.applySchemaChange` (which this exact Paimon test exercises). I checked the diff against both failing tests before concluding: the new/changed code paths in both files are gated behind checkpoint-restore state (`restoreCheckpointState()` only fires when `checkpointTables`/`historyTableChanges`/legacy `checkpointDataType` are non-null; `PaimonSinkWriter.applySchemaChange` only takes the new branch for `instanceof RestoreTableSchemaEvent`). Neither failing test is a failover/restore scenario — `testPostgresCdcSnapshotOnlyAndCommittedOffsetStartupModes` is a fresh-start snapshot/offset test, and `testSinkWithIncompatibleSchema` applies a plain (non-restore) `SchemaChangeEvent`, so both should be taking the unchanged code path. Combined with the failure shape (awaitility timeouts / lingering threads, not assertion-on-data mismatches or exceptions from the new code), this reads as e2e timing/container-teardown flakiness rather than a functional regression from this change — but I can't rule it out with 100% certainty from logs alone, so it's worth a clean rerun to confirm rather than dismissing outright. **Updated bottom line**: no confirmed source-level blocker from this pass. Recommend rerunning the three failed jobs; if `PostgresCDCIT` or `PaimonSinkCDCIT` fail again in the same way on a clean rerun, that would warrant a closer look at the restore-gated branches in `IncrementalSourceReader`/`PaimonSinkWriter` even though today's failures don't appear to hit them. -- 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]
