SEZ9 commented on issue #11965: URL: https://github.com/apache/seatunnel/issues/11965#issuecomment-5469327500
Thanks for clarifying that the config values were modified for security. Just to be safe: the earlier note about rotating credentials only applies if the `password` values are real — if you changed those too, no action is needed. On your question, a small correction to the mental model: on restart, SeaTunnel does not go back to the SCN recorded at the very first start. A fresh submission derives its startup position from `startup.mode` (defaulting to `initial` in your config), but a restarted job restores the checkpointed startup offset and continues from that persisted SCN rather than re-evaluating `startup.mode` against the current database state. So the resume point is the last checkpointed position — either way it is a stored SCN, not one recomputed after the source reset. That matches what you observed: the old task kept failing after the OGG/mirror rebuild, while the task recreated on August 27 runs normally, because there is currently no automatic "discard old checkpoint and restart from fresh Oracle state" recovery path. I don't have a verified command or debug flag to point you to for extracting the restored SCN, so I'd rather not guess. Since you can reproduce this easily, the evidence that would move this from expected restore semantics to a confirmed bug is still: 1. the exact restored SCN the failing old task resumes from; 2. verification that this SCN is still valid and available in the mirror after the OGG rebuild; 3. a failing log from a fresh job with no restored state (so far the fresh job is healthy); 4. confirmation of whether any old checkpoint/savepoint directory was reused when jobs were recreated. If you can capture the full logs from the failing restarted job on your next reproduction, that would help us locate the restored SCN and confirm whether it was genuinely still valid when the restore failed. <!-- streview-comment:676 --> -- 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]
