DanielLeens commented on issue #11965: URL: https://github.com/apache/seatunnel/issues/11965#issuecomment-5453915372
Thanks, this new data is the most important part of the thread. I rechecked the current Oracle-CDC path on `dev` (`1ff72ceb3d2a823a0fca64ec009984d75e846c28`). A fresh source derives its startup configuration from `startup.mode`, but a restored enumerator reuses the checkpointed startup offset instead of recomputing from the current database state. The base CDC assigner explicitly carries that restored startup offset forward across recovery. That matches what you observed: 1. the new task created on August 27, 2026 runs normally; 2. the restarted old task keeps following its previously persisted SCN path; 3. SeaTunnel does not currently have an automatic "discard old checkpoint and restart from fresh Oracle state" recovery path for this case. So, from the evidence in this issue, I still do not see proof that SeaTunnel moved the SCN backward by itself. The stronger explanation is that the persisted resume point became unusable for the rebuilt upstream capture path, while a fresh job on the rebuilt mirror is healthy. If you still think there is a product bug beyond that recovery limitation, the missing evidence would be: 1. the exact restored SCN used by the failing old task; 2. proof that the same SCN is still valid and available after the OGG / mirror rebuild; 3. a failing log from a fresh job with no restored state. Without that, this looks closer to expected restore semantics after an upstream reset than to a SeaTunnel CDC bug. -- 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]
