Skip to content

[Roadmap] Apache SeaTunnel 3.1.0 Roadmap #12949

Open

Description

@nzw921rx

Hello everyone,

Thank you for your active participation in the discussion on stability fixes after the Apache SeaTunnel 3.0.0 release.

This is a draft roadmap for 3.1.0 stability fixes, compiled from the fixes submitted by the community since the 3.0.0 release and the currently open pull requests.

It is only a discussion summary, not a final decision. You are welcome to suggest changes, add missing items, or claim any item you are interested in.

Priorities for this round: data correctness and data loss; Zeta recovery, checkpoint, and cancellation; hangs and leaks; type precision; well-scoped changes.
Release-blocking = must be merged before 3.1.0; non-blocking = may ship with 3.1.0 or in a later 3.1.x release.

Roadmap for Apache SeaTunnel 3.1.0:

P0 (Release-blocking)

Non-blocking

Prioritized for 3.1.0 (non-blocking)

Pending reassessment (not release-blocking)

Can follow in 3.1.x

Next steps:

Activity

  1. changed the title [-][Roadmap] Apache SeaTunnel 3.1.0 Bugfix Roadmap[/-] [+][Roadmap] Apache SeaTunnel 3.1.0 Roadmap[/+] on Oct 22, 2026
  2. added this to the 3.1.0 milestone on Oct 22, 2026
  3. pinned this issue on Oct 22, 2026
  4. added theissue type on Oct 22, 2026
  5. removed theissue type on Oct 22, 2026
  6. ricky2129 commented on Oct 22, 2026

    @ricky2129
    Collaborator

    @nzw921rx how abt including #12710 as well?

  7. SEZ9 commented on Oct 23, 2026

    @SEZ9
    Collaborator

    Thanks for putting this roadmap together. The split between release-blocking and non-blocking items looks reasonable to me, and the stated priorities (data correctness, Zeta recovery/checkpoint/cancellation, hangs and leaks, type precision) line up well with the P0 list.

    Regarding the suggestion to include #12710: could you share a short summary of what that fix addresses and which priority bucket you think it belongs in? That would help decide whether it fits this round.

    On the next-step questions, it would be useful if anyone proposing to upgrade a non-blocking item to P0 (or downgrade a P0 item) states the reasoning in terms of the listed priorities, so the final list stays well-scoped.

  8. nzw921rx commented on Oct 23, 2026

    @nzw921rx
    MemberAuthor

    10. @nzw921rx how abt including #12710 as well?

    Have you tested local compilation in non Docker mode? If you would like to be included in 3.1.0, please synchronize it in the email. Thank you

    mailing list thread: https://lists.apache.org/thread.html/mzo0o851k85qsgfw72n2k2lgwp217tt5

  9. ricky2129 commented on Oct 23, 2026

    @ricky2129
    Collaborator

    @nzw921rx yes, tested without Docker. I built the PR natively (./mvnw install -pl seatunnel-dist -am, Temurin 11, macOS, bash 3.2) and ran the dist scripts on the host:

    • foreground bin/seatunnel-cluster.sh: the script process becomes the JVM, a FakeSource→Console job runs 32/32, and SIGTERM to that PID exits 143 within 1s with the shutdown hook run;
    • -d daemon mode is unchanged; the job runs and stop-seatunnel-cluster.sh stops it;
    • on current dev, SIGTERM to the script kills only bash and leaves the JVM running, so systemd/supervisor setups are affected as well as containers.

    @SEZ9 summary: seatunnel-cluster.sh starts the JVM as a child of bash without exec, and the chart runs it under sh -c. SIGTERM never reaches the JVM, so every pod stop or rolling update ends in SIGKILL after the grace period: no shutdown hook, no clean Hazelcast leave, jobs replay from the last checkpoint. The fix is exec java in the script plus the exec-form command and terminationGracePeriodSeconds in the chart. I'd put it under Zeta recovery/checkpoint (every planned restart currently behaves like a crash), and it is a small, well-scoped change.

    I'll reply on the dev@ thread for 3.1.0.

  10. SEZ9 commented on Oct 24, 2026

    @SEZ9
    Collaborator

    @ricky2129 Thanks for the detailed native test report — building with ./mvnw install -pl seatunnel-dist -am on Temurin 11 / macOS / bash 3.2 and verifying both foreground bin/seatunnel-cluster.sh (SIGTERM → exit 143 with the shutdown hook run) and the unchanged -d daemon path with stop-seatunnel-cluster.sh is exactly what I was asking about. That answers my non-Docker question.

    I agree the scope is small and well-defined (exec java in the script plus the exec-form command and terminationGracePeriodSeconds in the chart), and placing it under Zeta recovery/checkpoint makes sense given that a planned restart currently behaves like a crash and forces a replay from the last checkpoint.

    Remaining asks before I add #12710 to the 3.1.0 list:

    1. Please post the same summary on the dev@ mailing list thread (https://lists.apache.org/thread.html/mzo0o851k85qsgfw72n2k2lgwp217tt5) so the inclusion is recorded there, as you said you would.
    2. Once that is on the list, ping me here and I'll update the issue body to add it under the Zeta section.
  11. JeremyXin commented on Oct 26, 2026

    @JeremyXin
    Contributor

    I’d like to propose adding these three PRs to the 3.1.0 roadmap:

    Would this prioritization fit the 3.1.0 scope?

  12. nzw921rx commented on Oct 26, 2026

    @nzw921rx
    MemberAuthor

    I’d like to propose adding these three PRs to the 3.1.0 roadmap:

    Would this prioritization fit the 3.1.0 scope?

    #12990 Please explain in the email, thank you.

    #11868 #12778 merged🔥

  13. JeremyXin commented on Oct 27, 2026

    @JeremyXin
    Contributor
  14. SEZ9 commented on Oct 27, 2026

    @SEZ9
    Collaborator

    Thanks @JeremyXin for the explanation. The fix for ChainedMapTransform deserialization is already listed under the P0 / Transform section of the roadmap in the issue description.

    As @nzw921rx asked, please make sure the same explanation goes to the dev mailing list so the release discussion has it on record there as well. If you have already sent it, a link to the mail thread here would be helpful.

  15. nzw921rx commented on Oct 27, 2026

    @nzw921rx
    MemberAuthor

    18. Hi community,

     I’d like to propose adding PR [#12990](https://github.com/apache/seatunnel/pull/12990) to the P0 / release-blocking list for SeaTunnel 3.1.0.
     
     This PR fixes ChainedMapTransform deserialization and preserves the serialVersionUID used by streams written before [#12804](https://github.com/apache/seatunnel/pull/12804). Since this affects restoring serialized state across upgrades, I believe it should be merged before the 3.1.0 release. Anyone who has time to review the PR would be greatly appreciated.
     
     
     Best,
     JeremyXin
    

    merged🚀

  16. SEZ9 commented on Oct 28, 2026

    @SEZ9
    Collaborator

    Thanks @JeremyXin for raising #12990 here. As @nzw921rx noted above, #12990 is now merged, so the ChainedMapTransform deserialization / serialVersionUID fix should land in 3.1.0 — no further action needed on the P0 request.

    One small ask: since the motivation was restoring serialized state across upgrades, could you confirm whether a restore from state written before #12804 has been verified against the merged code? If that's already covered by the tests in the PR, a quick note here is enough. Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions