DanielLeens commented on issue #11356: URL: https://github.com/apache/seatunnel/issues/11356#issuecomment-4888295989
This is a useful follow-up direction, but I would treat it as a design track rather than just “more CI cases”. The main question here is not only which scenarios to add, but what upgrade-compatibility contract SeaTunnel is actually willing to guarantee for persisted runtime state. That means the first design pass should make three boundaries explicit: 1. which restore/upgrade paths are release-blocking versus best-effort 2. which state surfaces must be covered in phase 2, and which can stay out of scope initially 3. how failures will be classified so maintainers can immediately see whether the break happened during state creation, restore, resume, or post-restore validation I would strongly suggest keeping the first STIP/output tight: define the compatibility contract, keep the scenario matrix small but high-risk, and avoid turning the first version into a broad “test everything” workflow. So from maintainer side, I think this issue is worth keeping open, but as a larger design/enhancement topic. If someone wants to push it forward, starting with the contract + scenario-boundary document will make the implementation much easier to review. -- 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]
