nitrajen opened a new pull request, #49696:
URL: https://github.com/apache/arrow/pull/49696
### Rationale for this change
`Schema.fbs` defines metadata keys and values as flatbuffer `string` fields,
which the flatbuffer spec requires to be valid UTF-8. PyArrow was silently
accepting arbitrary byte sequences, so it was possible to produce schemas that
violate the spec and fail to deserialize in other implementations (e.g. Rust's
`arrow2`, which enforces UTF-8 via `String`).
### What changes are included in this PR?
Validation is added in `KeyValueMetadata.__init__` — the single entry point
for all Python-side metadata construction. After converting each key and value
to bytes via the existing `tobytes()` call, we attempt `.decode('utf-8')` and
raise a `ValueError` with a clear message if it fails.
All write paths (`pa.schema()`, `pa.field()`, `Field.with_metadata()`,
`Schema.with_metadata()`) funnel through `ensure_metadata()` →
`KeyValueMetadata.__init__()`, so the check covers everything. `str` inputs are
unaffected since `tobytes()` already guarantees valid UTF-8 for those. The
`KeyValueMetadata.wrap()` path used for deserialization deliberately bypasses
`__init__` and is left unchanged.
The previous `test_undecodable_metadata` (ARROW-10214) tested that `repr()`
didn't crash on bytes that should never have been allowed in the first place.
It is replaced with `test_non_utf8_metadata_rejected` which tests the correct
contract.
### Are these changes tested?
Yes. The existing test suite (33 tests) passes without modification,
confirming no regressions. The new test covers: invalid bytes as a value,
invalid bytes as a key, invalid bytes on a field (not just a schema), and valid
UTF-8/ASCII inputs that must continue to work.
### Are there any user-facing changes?
Yes. `pa.schema()`, `pa.field()`, and `.with_metadata()` will now raise
`ValueError` when passed metadata keys or values containing non-UTF-8 bytes.
This was previously silently accepted.
* GitHub Issue: #49058
--
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]