hutiefang76 opened a new issue, #12929: URL: https://github.com/apache/seatunnel/issues/12929
### Search before asking - [x] Searched open PRs and issues for the failing test and superclass; no matching repair found. ### What happened A clean build of current dev fails `LLMBooleanOutputTest.readsLegacyFactoryWrapperWithValidationDisabled` before the LLM output assertions. The archived factory-wrapper stream introduced by #12194 has superclass UID `7090258061839605137`, while current `AbstractMultiCatalogTransform` has implicit UID `-3241928148724104003`. The same error occurs in both Linux/JDK 11 and Linux/JDK 17 [fork Build jobs](https://github.com/hutiefang76/seatunnel/actions/runs/39427092019), and in their edge-agent builds. I then reproduced it independently on unmodified official dev: 42 LLM tests, 41 passes and this one error, no skips. The JDBC test-only change in #12875 is not needed to reproduce it. The historical source explains the mismatch: #12804 (`f4474404f`) added `transformLevelConfig` and three protected methods to the serializable superclass without an explicit UID. The archived baseline is `8bea8c681cacccbd99fa642ca0853718980b9234`, before that change. Compiling the historical superclass with JDK 17 and running `serialver` gives `7090258061839605137`; the current class gives `-3241928148724104003`, matching both sides of the exception. This needs an explicit compatibility decision. Regenerating the stream against current helper classes removes coverage of the older wrapper hierarchy; pinning just the old UID also changes the identity of streams produced after #12804. Should the follow-up preserve that historical wrapper-restore contract, or isolate the LLM leaf-class compatibility regression from the helper hierarchy change? I am checking the fixture provenance in a separate worktree before changing source or archived bytes. Input from the authors of #12194 / #12804 would help settle that boundary. ### SeaTunnel Version Unmodified dev `1ce2d781566564d5bd603710e7442bd88c531414`. ### SeaTunnel Config No external job configuration is needed. The existing test uses `src/test/resources/llm/legacy-boolean-wrapper.base64` and its local HTTP test server; it fails during deserialization. ### Running Command ```shell ./mvnw -B -pl seatunnel-transforms-v2 -am package \ -Dtest=LLMBooleanOutputTest -DfailIfNoTests=false ``` ### Error Exception ```text java.io.InvalidClassException: org.apache.seatunnel.transform.common.AbstractMultiCatalogTransform; local class incompatible: stream classdesc serialVersionUID = 7090258061839605137, local class serialVersionUID = -3241928148724104003 at LLMBooleanOutputTest.readsLegacyFactoryWrapperWithValidationDisabled(LLMBooleanOutputTest.java:248) ``` ### Java or Scala Version Local reproduction and source/UID checks: Microsoft OpenJDK 17.0.18. The linked CI reproduces the same failure on JDK 11 and 17. No cluster-upgrade run is claimed. ### Are you willing to submit PR? - [x] Yes, once the compatibility boundary is agreed and concurrent work is checked. ### Code of Conduct - [x] 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]
