DanielLeens opened a new issue, #11239:
URL: https://github.com/apache/seatunnel/issues/11239
## Search before asking
I searched existing feature issues and did not find a dedicated proposal for
a `dev`-branch upgrade-compatibility CI that validates cross-version restore
paths.
## Description
SeaTunnel currently has strong build, unit-test, integration-test, and E2E
coverage, but `dev` does not have a dedicated workflow that proves upgrade
compatibility for persisted runtime state.
This gap matters because SeaTunnel has multiple stateful upgrade surfaces:
- checkpoint / savepoint restore
- source enumerator state restore
- sink writer state restore
- CDC resume / restore after upgrade
- serialized job graph and config compatibility
Recent issue patterns show that this is not a theoretical risk:
- Flink restore from checkpoint/savepoint across versions has already been
reported in `#10177` and `#10193`
- serialized compatibility gaps for job-graph/config classes were raised in
`#11020`
- restore-related regressions have repeatedly appeared in CDC and
sink-related changes
As a result, we can pass normal CI but still break a real user upgrade path.
I would like to propose a dedicated **upgrade-compatibility CI** for the
`dev` branch.
## Proposed scope
The first version should stay intentionally small and high-signal.
### Phase 1
Add a workflow that validates **previous stable version -> current `dev`**
restore compatibility for a few representative stateful scenarios.
Suggested initial scenarios:
1. **Zeta engine restore**
- Start a minimal streaming job on the previous stable version
- Produce checkpoint/savepoint/state
- Upgrade to current `dev`
- Restore and verify that the job resumes successfully
2. **Flink engine restore**
- Use a minimal source/sink pipeline on the previous stable version
- Restore from checkpoint/savepoint on current `dev`
- Verify that the job continues processing correctly
3. **CDC resume / restore**
- Run a CDC source job long enough to persist state
- Upgrade to current `dev`
- Restore and verify incremental consumption continues correctly
4. **Sink writer / multi-table restore**
- Cover a representative sink path that persists writer state
- Verify restore succeeds after upgrade
### Trigger strategy
To keep the workflow practical and stable, I suggest this rollout:
- start with `workflow_dispatch` and a nightly scheduled run on `dev`
- do **not** gate every PR at the beginning
- after the workflow becomes stable, consider selective PR triggering when
changes touch high-risk areas such as:
- `seatunnel-api`
- `seatunnel-engine`
- Flink translation / restore code paths
- CDC connectors
- source/sink state serialization and restore logic
## Out of scope
This proposal is **not** asking for:
- a full compatibility matrix for every connector
- a metadata-schema upgrade workflow like control-plane projects
- a blocking PR gate for all changes from day one
The goal is to add a small but meaningful early-warning system for stateful
upgrade regressions.
## Acceptance criteria
A first implementation would be successful if:
- there is a reproducible GitHub Actions workflow for upgrade compatibility
on `dev`
- it covers at least 2-4 representative restore scenarios
- failures clearly indicate which upgrade stage broke
- the workflow documents what compatibility guarantee it is actually
asserting
## Usage Scenario
Maintainers and contributors need an early signal when a change breaks real
upgrade paths that depend on persisted state.
This is especially important for users running long-lived streaming or CDC
jobs, where a regression may only appear during upgrade or restore, not during
fresh deployment.
## Related issues
- `#10177`
- `#10193`
- `#11020`
## Are you willing to submit a PR?
I am willing to help refine the scope and review a focused implementation.
If the community agrees on the initial scenario set, this looks like a good
`help wanted` item.
## Code of Conduct
I agree to follow this project's Code of Conduct.
--
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]
