loustler opened a new issue, #11743: URL: https://github.com/apache/seatunnel/issues/11743
### Search before asking - [X] I had searched in the [issues](https://github.com/apache/seatunnel/issues?q=is%3Aissue+label%3A%22bug%22) and found no similar issues. ### What happened `ParquetWriteStrategy#getOrCreateOutputStream` registers three Avro logical-type conversions on the data model it hands to `AvroParquetWriter`. The third one looks unreachable, and this issue is to settle whether it is. ```java dataModel.addLogicalTypeConversion(new Conversions.DecimalConversion()); dataModel.addLogicalTypeConversion(new TimeConversions.DateConversion()); dataModel.addLogicalTypeConversion(new TimeConversions.LocalTimestampMillisConversion()); ``` `TimeConversions.LocalTimestampMillisConversion` handles the Avro logical type **`local-timestamp-millis`**. But a SeaTunnel `TIMESTAMP` column is written as `INT64 .as(OriginalType.TIMESTAMP_MILLIS)` in `ParquetWriteStrategy#seaTunnelDataType2ParquetDataType`, and parquet-avro's `AvroSchemaConverter` maps that to **`timestamp-millis`**. Those are different logical types, so nothing on this path should ever ask the model for the `local-timestamp-millis` conversion. Reinforcing that: `resolveObject` converts `LocalDateTime` by hand rather than leaving it to the data model, so even the value path does not route through the conversion. **This is not proven, which is why it is an issue rather than a PR.** I have not shown that no code path produces a `local-timestamp-millis` schema — a different write path, a schema supplied rather than derived, or a future type mapping could. Removing a registration that turns out to be live would silently corrupt timestamps, so the removal is only safe once reachability is actually settled. ### What to check 1. Whether any path through `seaTunnelDataType2ParquetDataType` / `buildAvroSchemaWithRowType` can yield `local-timestamp-millis`. 2. Whether `resolveObject`'s manual `LocalDateTime` handling makes the registration dead even when the schema does carry that logical type. 3. If both come back negative, remove the registration — and if not, the schema/conversion mismatch is worth a comment so the next reader does not repeat this analysis. ### Context Raised during review of #11660, which relocated these three registrations from per-row to per-file but deliberately did not change what is registered. Analysis originally posted in [this comment](https://github.com/apache/seatunnel/pull/11660#issuecomment-5191004346); @SEZ9 asked for it to be captured separately so it is not lost in that thread. A logical-type round-trip test is what would surface this. #11660 adds one (`testLogicalTypesRoundTripAcrossReusedWriter`), and it passes — which is consistent with the conversion being unnecessary, but does not by itself prove it, since a passing round trip does not distinguish "the conversion was not needed" from "the conversion was used and worked." ### SeaTunnel Version dev ### SeaTunnel Config ```conf N/A - code-level question, not a runtime failure. ``` ### Running Command ```shell N/A ``` ### Error Exception ```log N/A - no exception; this is a reachability question about a registered converter. ``` ### Zeta or Flink or Spark Version Zeta ### Java or Scala Version _No response_ ### Screenshots _No response_ ### Are you willing to submit PR? - [ ] Yes I am willing to submit a PR! Willing to do the reachability investigation and submit the removal if it comes back dead, but I would rather someone who knows the Avro schema-derivation path confirm the analysis first. ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/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]
