DanielLeens commented on PR #11503: URL: https://github.com/apache/seatunnel/pull/11503#issuecomment-5369031718
@dybyte good question, and I agree with the direction. The manual failover validation described in the PR body (two consecutive Worker failures/recoveries, 139 checkpoints with 0 failed / 2 restored on the MySQL-to-Console path, plus the MySQL-to-JDBC run) is real signal, but it's exactly the kind of thing that should also live as a repeatable Zeta E2E case rather than only a one-off manual run — this PR's own restore path (`IncrementalSourceReader` restoring `checkpointTables`/`historyTableChanges`, `RestoreTableSchemaEvent` propagation through transforms and schema-aware sinks) is precisely the kind of cross-cutting change that regresses silently without a pinned automated scenario. Concretely, I'd suggest a dedicated `seatunnel-e2e` case that: starts a Zeta job against MySQL CDC with a schema-aware sink (JDBC or File, matching what was manually validated), issues a DDL `ALTER TABLE ... ADD COLUMN` while a checkpoint is in flight, kills/restarts the TaskExecutionServer to force restore-from-checkpoint, then asserts both that the restored rows carry the new column and that no duplicate physical DDL is re-applied on the sink side. That would pin the exact failover scenario currently only covered by unit tests (`RestoreTableSchemaEventTest`, the CDC restore suite) plus manual validation. I don't consider this a hard blocker for the current head given the existing unit coverage and the two independent manual validation runs already documented, but it'd meaningfully raise confidence for a change this central to failover correctness — worth adding either in this PR or as an immediate fast-follow. -- 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]
