DanielLeens commented on issue #11965: URL: https://github.com/apache/seatunnel/issues/11965#issuecomment-5468621798
Thanks, this follow-up clarifies the operational question. I rechecked the current Oracle-CDC restore path on `dev` again. The important distinction is: 1. for a **fresh** job, `startup.mode` is resolved when the source is created; 2. for a **restored** job, SeaTunnel reuses the offset that was already checkpointed for that job state, rather than asking Oracle for a brand new start SCN on every restart. So the behavior is not "keep the SCN from the very first startup forever". It is closer to "keep resuming from the last persisted checkpoint/savepoint offset for that existing job state". On the current code path, I do **not** see a dedicated CLI or REST command that prints that restored Oracle SCN directly from saved state. The most practical verification path available today is: 1. reproduce on the **old restored job**, not the newly created fresh job; 2. enable DEBUG logging for the Oracle CDC / LogMiner path and capture the lines that print `Offset SCN` and `Offset Commit SCN` during the failing restart; 3. compare that restored SCN with the earliest SCN still available in the redo/archive window after the OGG rebuild. That evidence would answer the key question here: whether the restarted old job is simply resuming from an old persisted offset that is no longer valid after the upstream reset, or whether a fresh job with no reused state can also fail the same way. So if you continue this investigation, the most useful next update would be: 1. the DEBUG log from the failing **restored old job** showing the `Offset SCN`; 2. confirmation of whether that SCN still exists in the Oracle redo/archive range after the OGG rebuild; 3. confirmation that the fresh job created on August 27, 2026 stays healthy over time without reusing the old checkpoint/savepoint state. With those three points, maintainers can verify whether this is mainly an offset-observability gap around restore semantics, or a deeper Oracle-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]
