DanielLeens commented on issue #10926: URL: https://github.com/apache/seatunnel/issues/10926#issuecomment-4597810345
I checked the current Zeta-side restore path in the codebase, and this does look like a real capability gap rather than a connector-specific bug. Today the operator-facing restore entry is still explicitly modeled as savepoint-based restore by job id. The CLI already exposes `-r/--restore`, but that path is tied to an explicit restore job id, while checkpoint overview/history are mainly inspection utilities. I do not see a clear upstream contract yet for the different case described here: a streaming job is force-stopped externally, and the next run should resume from the latest successful checkpoint automatically or through a clearly supported restart workflow. So I think this is worth tracking as a Zeta feature request. The most useful way to narrow it would be: 1. keep the first scope Zeta-only 2. define how the latest successful checkpoint is discovered and bound to the next run 3. make the fallback behavior explicit when the checkpoint has been cleaned up, is incompatible, or restore fails partway 4. document the source / transform / sink restore expectations for this restart path, so operators are not guessing from implementation details We already have important building blocks in place on the state snapshot side, but the job-lifecycle-level recovery contract is still the missing piece here. We've kept this under `feature` + `help wanted` for now. Contributions are very welcome once the first scope is narrowed. -- 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]
