DanielLeens commented on issue #11020: URL: https://github.com/apache/seatunnel/issues/11020#issuecomment-4644692696
Thanks for raising both parts of this so clearly. I checked the current `SerialVersionUIDCheckerTest` path, and the concrete gap you pointed out is real: today the check is centered on classes that implement `SeaTunnelSource` or `SeaTunnelSink`, so it can miss other classes that still end up serialized inside the job graph, such as config factories or config objects. Extending the checker in that direction sounds reasonable. At the same time, I agree with your broader concern that `serialVersionUID` alone is not a complete compatibility guarantee. It can prevent one hard-failure class (`InvalidClassException`), but it does not by itself protect us from silent semantic changes when new fields are introduced and deserialized old state comes back with `0` / `null` values. So I would separate this into two layers: 1. a practical improvement: broaden the checker so it covers the job-graph classes that are actually serialized during restore paths; 2. a design/compatibility question: define more clearly what upgrade path SeaTunnel officially supports for serialized runtime state, and what compatibility expectations we want to guarantee across versions. My suggestion would be to keep the first step small and concrete. A PR that extends the checker coverage to the relevant config/config-factory/job-graph classes would be useful on its own, even before we fully settle the larger cross-version state policy. For the broader question, I do not think we should imply that “having a fixed UID” means cross-version restore is generally safe. If we want to support that path more explicitly, we likely need clearer project guidance on when stop-with-savepoint + resubmit is the expected upgrade path, and what coding rules serialized state/config classes should follow when fields evolve. So yes — the checker extension looks like a good contribution direction, and the larger compatibility question is also worth documenting more explicitly rather than leaving it implicit. -- 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]
