SEPURI-SAI-KRISHNA commented on issue #11406:
URL: https://github.com/apache/seatunnel/issues/11406#issuecomment-6415615724
@DanielLeens your last point asked for the missing piece: a concrete
incompatibility example and the exact error shape. Measured on JDK 17 against
current `dev`.
**The example.** `ChainedMapTransform` gained a field in #12804 with no
pinned UID. Writing state before that commit and reading it after gives:
```
java.io.InvalidClassException: ...ChainedMapTransform; local class
incompatible:
stream classdesc serialVersionUID = 8769738606872706499,
local class serialVersionUID = 4659105814088680487
```
**Why this argues for the contract.** That error is the *good* outcome. If a
maintainer pins the old UID, which is what #12938 did for a sibling class,
deserialization succeeds and the field restores as `null`. The job then fails
with a `NullPointerException` on the first row, and the schema-change path
fails too. So one root cause gives either a loud startup error or a silent
restore then a data-path crash, depending on the remedy picked. That is the
"inconsistent restore failures across connectors" you warned about, and release
notes do not fix it.
This also confirms @det101's point by measurement: the UID tracks field
layout, not semantics. Marking that field `transient` moves it back to
`8769738606872706499` with no behaviour change.
**One input not yet raised here.** There are two serialization worlds, and a
v1 contract covering one leaves the other silent:
- Connector split and enumerator state: `SeaTunnelSource` defaults both
serializers to `DefaultSerializer`, i.e. `SerializationUtils`, plain Java
serialization. Exactly one connector supplies its own, Firebase. So the UID
governs restore for almost every connector.
- Engine checkpoint storage: `AbstractCheckpointStorage` hard-codes `new
ProtoStuffSerializer()`. Protostuff never reads the UID, and a field added
later is skipped and returns its default, as the repo's own
`WALReaderAndWriterTest` notes.
So the Java path fails loudly on a UID change while protostuff accepts the
old bytes and silently defaults the new field. Opposite failure modes, same
logical event.
I have the probes, the before and after streams, and a measured fix shape
for the Java-serialization side, so I can take a slice of this forward rather
than only describe it. If the four points are close to settled, say which slice
is most useful and I will open a PR. Otherwise I can start from a focused issue
so this discussion is not blocked.
--
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]
