voonhous commented on PR #19366: URL: https://github.com/apache/hudi/pull/19366#issuecomment-5091105858
Closing -- **no-op on master**, and duplicates #18574. `ProtoConversionUtil.java:231` builds every field via `HoodieSchemaField.of` -> `HoodieAvroUtils.createNewSchemaField` -> `convertDefaultValueForAvroCompatibility` (`HoodieAvroUtils.java:1552`), which already applies the identical `new String(bytes, ISO_8859_1)` to any `byte[]` default on Avro 1.12+. Ran `getSchemaForMessageClass(Sample.class, ...)` against the built jar with Avro swapped on the classpath: | | 1.11.4 | 1.12.0 | 1.12.1 | |---|---|---|---| | master | OK | OK | OK | | master + this patch | OK | OK | OK | | pre-#17740 `new Schema.Field(..., byte[9])` (control) | OK | FAIL | FAIL | master and master+patch emit byte-identical schema JSON in every cell. The control reproduces the reported `"AAAAAAAAAAAA"` error exactly -- so the bug was real, and was fixed on 2026-01-02 by `c177e2be6b35` (#17740), when field construction moved off raw `new Schema.Field`. The added test can't fail either way: Azure runs `hudi-utilities` on Avro 1.11.4, where 1.11 renders the `byte[]` correctly on its own. Avro 1.12.x is `spark4.x`-only and no job runs this module under it. Good analysis of the 1.12 validator change -- it just landed after the code path had already moved. -- 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]
