voonhous commented on PR #18574: URL: https://github.com/apache/hudi/pull/18574#issuecomment-5091106113
Closing -- **no-op on master**. #19366 makes the identical change; closing both. `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 `"AAAAAAAAAAAA"` error from #18573 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`. That predates this PR, which is why the empirical probe in the issue (raw Avro `Schema.Field`) no longer matches what Hudi does. 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. `validateOldProtoReadWithNewSchema` also already asserts this default decodes to a zero `GenericFixed`. -- 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]
