fix: byte-order handling for structured dtypes in the bytes codec#220
Merged
Conversation
The bytes codec neither byte-swapped structured-dtype fields to its configured endian on encode (numpy reports byteorder '|' for void dtypes, so the top-level byteorder comparison never detected a mismatch) nor honored its endian when decoding, silently corrupting any structured data whose field byte order differed from the stored one (e.g. virtual references to external big-endian data). Encode now detects byte-order mismatches by comparing full dtypes via newbyteorder, and decode reinterprets raw bytes in the stored byte order before converting to the data type's declared byte order, so the stored layout (codec state) and the in-memory layout (array data type) are independent. Closes zarr-developers#4141 Assisted-by: ClaudeCode:claude-fable-5
Extend test_endian's parametrization with structured dtypes and test_bytes_codec_sync_roundtrip with endian/dtype parametrization plus stored-layout and decoded-dtype assertions, instead of adding parallel test functions for the same properties. Assisted-by: ClaudeCode:claude-fable-5
The variable is the dtype used to view the raw chunk bytes (byte order from the codec's endian configuration), not a property of the stored data or of the returned buffer, which always carries the array's declared dtype. Assisted-by: ClaudeCode:claude-fable-5
Assisted-by: ClaudeCode:claude-fable-5
d-v-b
force-pushed
the
claude/zarr-python-4141-543977
branch
from
bfea033 to
e110bf6
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 AI text below 🤖
Summary
Fixes zarr-developers#4141: the
bytescodec silently corrupted structured-dtype data whose field byte order differed from the stored one.Two defects, both in
BytesCodec:self.endianagainst the buffer's top-level byteorder, but numpy reports'|'for void dtypes, so struct fields were never swapped — big-endian input was written raw underendian: littlemetadata, corrupting even a pure zarr write/read roundtrip.endianfor scalar (HasEndianness) dtypes and viewed struct chunks in the fields' native byte order — the silent-corruption path for virtual references to external big-endian data (e.g. FITS binary tables via VirtualiZarr).The fix keeps stored and in-memory byte order independent, per the struct data type spec (field data types carry no byte order; the codec's
endiangoverns all multi-byte fields):newbyteorder(self.endian), converting to the stored order when they differ.Note: v3 metadata carries no per-field byte order, so a reopened array always declares native-endian fields and reads now return correctly byte-swapped native values. Per-field endianness of the dtype declaration still doesn't survive a metadata roundtrip — that would be a metadata/API feature, distinct from this corruption fix.
For reviewers
The decode-side contract change (decoded buffers now always come back in the declared dtype's byte order, converting when needed) is the part worth a second look — it slightly changes what
_decode_syncreturns for non-native scalar dtypes, though the user-visible result was already cast by the out-buffer assignment. Encode-side and the tests are straightforward.Author attestation
TODO
docs/user-guide/*.md(n/a)changes/🤖 Generated with Claude Code