Skip to content

Commit a9370dd

Browse files
d-v-bclaude
andauthored
fix(chunk-grids): require chunk sizes of at least 1 and read the 0, false and true sizes older releases stored (zarr-developers#4334)
* fix(chunk-grids): enforce one zero-length-axis invariant across model, clamps and metadata Invariant: a chunk edge length is always >= 1; a dimension's extent may be 0, in which case the dimension has zero chunks (ceildiv(0, size) == 0). Zero-length-axis bugs have recurred since 2017 (#150, #241, #303, zarr-developers#972, zarr-developers#1977, zarr-developers#2434, zarr-developers#3711, zarr-developers#4305, zarr-developers#4307, zarr-developers#4328) because the layers disagreed on this invariant and every span-derived chunk spelling clamped on its own: - The metadata layer (common.py, metadata/v3.py) required chunk edges >= 1, but the in-memory FixedDimension allowed size == 0 with four special-case branches left over from zarr-developers#2434, so normalization could build a grid the metadata constructor then rejected. FixedDimension now rejects size < 1 and the four `if self.size == 0` branches are gone. VaryingDimension already required edges > 0 and is unchanged. - `chunks=-1`, `chunks=False`, `chunks="auto"` (_guess_regular_chunks, both the typesize == 0 early return and the np.maximum line) and `shards="auto"` each derived "one chunk covering the axis" independently. They now all go through one helper, `_full_span_chunk_size(span) = max(span, 1)`, which is the single definition of that phrase for a possibly zero-length axis. - Zarr format 2 metadata had no chunk >= 1 check, so a legacy `chunks: [0]` document opened fine and read uninitialised memory after a resize. It now raises a clear ValueError at parse time, matching the format 3 grid. - Rectilinear grids had no creation-time spelling for a zero-length axis: normalize_chunks_1d required sum(edges) == span, which no list of positive edges can satisfy for span 0, even though the same state is reachable via resize((0,)) and round-trips through reopen. For span == 0 any non-empty list of positive edges is now accepted verbatim, producing the same VaryingDimension(edges, extent=0) that resize produces; the strict sum check is kept for span > 0. Tests: the per-spelling regression test from zarr-developers#4328 is replaced by one matrix over {-1, False, "auto", 1, (1,...), [[2, 2]]} x {(0,), (0, 4), (4, 0), (0, 0), ()} x {v2, v3} x {no shards, shards="auto" with and without a byte budget, explicit shards}, with separate small tests for each error case. Tests that constructed FixedDimension(size=0) now assert it raises, and a zero-extent test covers the behaviour the old special cases were guarding. Assisted-by: ClaudeCode:claude-fable-5-1 * fix(metadata): read a legacy v2 zero chunk edge on an empty axis as 1 zarr-python 2.18.7 writes `chunks: [0]` for `zarr.zeros((0,), chunks=False)` and for `chunks=(0,)`, so stores with that document exist. Rejecting them at open would turn a previously-readable array into an error; leaving the 0 in place read uninitialised memory after a resize. Normalize the edge to 1 with a ZarrUserWarning instead — the same grid every other "one chunk spans the axis" spelling produces — and keep rejecting a zero edge on an axis that has data. Assisted-by: ClaudeCode:claude-fable-5-1 * chore: rename changelog fragment to the PR number Assisted-by: ClaudeCode:claude-fable-5-1 * docs: state what 2.x actually did with a zero chunk edge Measured against zarr 2.18.7: `zeros((0,), chunks=False)`, `chunks=-1` and `chunks=(0,)` all write `chunks: [0]`, after which nchunks, read, write, append, resize and reopen-then-read every raise ZeroDivisionError. There was never a working behaviour to preserve; normalizing the edge to 1 makes such arrays usable for the first time. Say so in the comment and fragment instead of claiming the stores were previously readable. Assisted-by: ClaudeCode:claude-fable-5-1 * docs: qualify zero-chunk compatibility history Assisted-by: Codex:GPT-6 * fix(metadata): read a legacy zero chunk size on an empty axis in Zarr format 3 The compatibility policy for a stored chunk size of 0 on a zero-length axis covered Zarr format 2 only, so arrays written by zarr-python 3.0 and 3.1 with `chunk_shape: [0]` — or `[false]`, which 3.0 wrote for `chunks=False` — still could not be opened at all. `ArrayV3Metadata` now applies the same policy to a regular chunk grid: a stored chunk size of 0 on a zero-length axis is read as 1 with a `ZarrUserWarning`, and a zero chunk size on a positive-length axis is left for the chunk grid parser to reject. It runs in `__init__` rather than in the grid parser because the policy needs the array shape, which chunk grid metadata does not carry. Both warnings now say how to store a corrected chunk size — open the array writable and call `array.update_attributes({})`, which rewrites the whole document from the parsed metadata — from one shared constant. The Zarr format 2 warning also named only zarr-python 2.x; measured against real installs, every 3.x release before 3.4 wrote a zero chunk size for an empty array too (3.3.0 for `chunks=-1` and `chunks=False`). Tested against stores written by zarr 3.0.10, 3.1.6 and 3.3.0: they open, append without losing data, and re-save to a chunk size that reopens without a warning. Assisted-by: ClaudeCode:claude-opus-5 * refactor(metadata): check stored chunk shapes against the array shape in one routine The legacy zero-chunk policy was written out twice: inline in `ArrayV2Metadata.__init__`, and again in a Zarr format 3 helper. The V2 copy also zipped with `strict=False` and re-appended any trailing chunk entries only so that a separate length check, `parse_metadata`, could report a dimensionality mismatch after construction. `parse_stored_chunk_shape` in `zarr.core.metadata.common` is now the one place a stored chunk shape is checked against its array's shape, for both formats: one entry per axis, every integer chunk size at least 1, and a size of 0 (or JSON `false`) on a zero-length axis read as 1 with a warning that names the writer and how to re-save. Non-integer entries, such as edge lists, pass through for the caller's own parser. `ArrayV2Metadata.__init__` calls it directly and `parse_metadata` is gone. The Zarr format 3 adapter only locates a regular grid's `chunk_shape` in the stored document and hands it over; it still runs in `ArrayV3Metadata.__init__` because chunk grid metadata has no array shape. The Zarr format 3 import changes that existed only for the old helper are reverted. Tests for the policy now target the routine: one table of valid and legacy inputs, and one test per rejection (dimension mismatch, zero on a non-empty axis, negative). They replace metadata-level tests in test_v2.py and test_v3.py that only re-tested the same rules; the end-to-end tests still cover both formats' wiring against stored arrays. Assisted-by: ClaudeCode:claude-opus-5 * refactor(metadata): scope the stored chunk shape check to regular chunk grids `parse_stored_chunk_shape` passed non-integer entries through "for the caller's own parser", which made a regular-grid policy look like a general chunk shape routine and let it decide what a 0-length chunk means for grids it does not own. A rectilinear grid, or any other grid, is free to define its own semantics for 0-length chunks. It is now `parse_stored_regular_chunk_shape`, typed `Sequence[int]`, with no pass-through, and its docstring says it applies to Zarr format 2 `chunks` and Zarr format 3 `regular` grids only. The Zarr format 3 caller hands it a chunk shape only when the grid is named `regular` and every entry is an integer (`_is_regular_chunk_shape`); anything else is not a regular chunk shape and goes to the chunk grid parser untouched. Assisted-by: ClaudeCode:claude-opus-5 * fix(metadata): read a stored zero chunk size on a grown axis as one spanning chunk A stored chunk size of 0 was tolerated only on a zero-length axis and rejected otherwise, because the metadata supposedly could not say how the stored chunks were laid out. But a chunk size of 0 gives a grid of zero chunks, so no release could store a chunk under it, and the writers of that metadata let the axis grow: 3.4.0 appends to a Zarr format 2 array created empty by 3.3.0 (shape grows, no chunk written), and 3.1.6 records a Zarr format 3 resize and the resize half of a failed append. Measured with real installs. Those arrays open in 3.4.0, attributes included; the rejection would have made them unopenable. `parse_stored_regular_chunk_shape` now reads a stored 0 (or JSON `false`) on any axis as one chunk spanning it, `max(extent, 1)`, which is what the `-1`/`False` spec that wrote it meant. On a grown axis the warning also says that data written to it was not saved. Negative sizes are still rejected. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test: a stateful test of one array's create/append/resize/write life The only state machine that touched arrays compared zarr on one store with zarr on a MemoryStore, so a chunk grid bug showed up identically on both sides; it had no append rule, covered Zarr format 3 only, and kept every empty axis at 0 when resizing, which is where the zero-length bugs live. `ArrayLifecycle` checks one array against a NumPy model across both formats, every chunk spelling (-1, False, "auto", ints, sharded, rectilinear) and the stored chunk size of 0 that releases before 3.4 wrote, including on an axis those releases grew. Rules append, resize (growing and shrinking to and from 0), write and re-save the metadata; the invariant reopens the array and compares shape, values and whether the legacy warning is due. Deliberately breaking the grown-axis policy, the legacy warning, or append on an empty axis each fails it. `resize` keeps partly retained chunks whole, so cells cut off by a shrink can come back with their old values when the axis grows (as in 2.x); the model marks such cells unknown until written instead of encoding that. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(metadata): stop the zero chunk size warning from naming writers The warning for a stored chunk size of 0 said which zarr-python releases wrote it. The check runs on every metadata construction, so metadata built in code, such as VirtualiZarr's kerchunk writer passing an empty array's shape as `chunks`, was told it came from zarr-python 2.x. The warning now says what the chunk size is read as and, on an axis of positive length, that the axis holds only the fill value. `legacy_writers` is gone, and the docstrings no longer narrate release history; the changelog keeps it. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * chore(metadata): drop an orphaned comment in ArrayV2Metadata.__init__ The comment introduced a consistency check (`parse_metadata`) that this branch removed; the check now lives in `parse_stored_regular_chunk_shape`. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(chunk-grids): size a full-span shard as a multiple of the inner chunk One definition of "one chunk spanning the axis", full_span_chunk_size(span, unit), is the smallest positive multiple of unit covering span. shards=-1 and shards=False now use the inner chunk size as unit, so a zero-length axis, or one whose length is not a multiple of the inner chunk, gets a valid shard instead of a divisibility error. The zero-length array test drops the explicit-size spellings and keeps the spellings that derive a chunk from the span. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor(metadata): read invalid stored chunk sizes in one module of document upgrades The metadata constructors are strict again: a chunk edge length is an int of at least 1, so metadata built in code with 0 or True raises, without a warning. Stored documents are read leniently only in zarr.core.metadata.upgrades, whose upgrades map a stored array document to a valid one before the constructors run. ArrayV2Metadata.from_dict and ArrayV3Metadata.from_dict apply them, so opening an array and parsing consolidated metadata take the same path. The first upgrade reads a regular chunk size of 0 or JSON false as one chunk spanning the axis, a multiple of the inner chunk size when the array is sharded (this opens sharded stores with an outer chunk size of 0), and JSON true, which real releases wrote for chunks=(True,), as 1. Its one warning says what is invalid, how it is read, and how to re-save, including zarr.consolidate_metadata. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs: rewrite the 4334 changelog fragment and trim restating docstrings The fragment now covers the full-span shard rule, strict constructors, and the stored-document upgrade (including JSON true) in two short paragraphs. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test: model exactly what the store holds in the array lifecycle state machine The model now tracks cells beyond the array's shape: a shrinking resize deletes exactly the chunks outside the new grid, kept chunks keep their out-of-bounds cells, and a write covering every in-bounds cell of an unsharded chunk resets its out-of-bounds cells to the fill value. A resize that never deletes chunks now fails the test. Sharding is its own chunk spelling, a stored chunk size of 0 applies to sharded arrays too (in the outer grid), re-saving metadata only runs when the store warns, and the test takes its settings from the repository's hypothesis profiles under the slow_hypothesis marker, like the other stateful tests. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor(metadata): warn about an upgraded document only once it validates An upgrade now returns the upgraded document and how it read it, and `from_dict` warns with those readings after the metadata constructor accepts the upgraded document. A stored document that is still invalid after an upgrade raises its own error instead of first warning how it was read. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor(metadata): one per-axis rule for stored chunk sizes, one rule for edges Stored regular chunk shapes, in both formats and in a sharding codec's inner chunk shape, are read entry by entry by one rule in upgrades.py: an int >= 1 is kept, `true` is read as 1 (zarr 3.0.10 also wrote it as the inner chunk size of a shard, which the sharding codec used to read silently), and 0 or `false` as one chunk spanning the axis. Integral floats are not read: no release wrote a regular grid with them. A document warns once, naming the array where the caller knows its path. Metadata constructors check every chunk edge length with one function, `parse_chunk_edge`, which tells a wrong type (TypeError) from a wrong value (ValueError); this covers bare sizes, rectilinear edges, RLE sizes and the sharding codec's inner chunk shape. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor(chunk-grids): start chunk guessing from the one full-span rule `_guess_regular_chunks` clamped zero-length axes with `np.maximum`, restating `full_span_chunk_size` with unit 1. Fold the zero-span normalizer tests into the `normalize_chunks_1d` tables. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test: run the array lifecycle state machine in the slow Hypothesis job Add it to `just hypothesis`. Re-saving metadata is always enabled and must leave valid metadata unchanged; appends favour an axis stored with chunk size 0, which raises how often a legacy axis grows before it is re-saved. A fixed example pins that a write to a shard kept by a shrink leaves its cells beyond the shape alone. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(array): store upgraded metadata before writing the first chunk An array read from a stored document that the upgrades had to correct (a chunk size of 0, `false` or `true`) wrote chunks under the corrected layout while the store kept the old document, so zarr 3.2.1-3.4.0 then read only the fill value, and tensorstore and zarrs could not open it. `from_dict` now marks the metadata it read from an upgraded document (`_stored_document_upgraded`, a field outside the document and equality), and `AsyncArray._set_selection`, which every chunk write goes through (`setitem` now included), stores that metadata first and keeps the stored copy. Concurrent first writes store the same document. The array lifecycle state machine now ends the legacy state on a write and checks that no chunk is stored under a document that is still upgraded on read; `resave_metadata` runs only while the stored document is invalid, and re-saving valid metadata is checked once, at creation. The changelog also says which releases stored a chunk size of 0 on an axis of positive length. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor(metadata): name an array one way in upgrade warnings Warnings about an upgraded document name the array by its store path, `str(StorePath(store, path))`, on every path that reads one: opening an array, `AsyncArray.from_dict`, a group read with or without consolidated metadata, and consolidated members, which were named relative to the group. `GroupMetadata.from_dict` and `ConsolidatedMetadata.from_dict` take the group's path for that. The consolidated test now also opens the group with `use_consolidated=False` and checks each array's name, so dropping the path on either read path fails a test. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * refactor(metadata): one rule for bare sizes and edge lists; one noun in messages - `_validate_chunk_shapes` decides "edge list or bare size" with one `match`: a list or tuple is an edge list, anything else is a bare size checked by `parse_chunk_edge`, so a string dimension such as `"10"` is rejected as not an int instead of being iterated per character. Stored rectilinear `from_dict` makes the same JSON split and passes the dimension to `expand_rle`, so an invalid edge or RLE count inside a list names its dimension. - Messages say "dimension" throughout, lowercase after the colon ("Dimension 0: chunk edge length must be >= 1, got 0"); the upgrade warnings read "0 in dimension 0 as one chunk spanning the dimension". - The upgrades test for JSON arrays with `list` only (a stored document holds no tuples), and `_read_chunk_size` says what `span=None` means. - `ArrayV2Metadata.from_dict` copies the document once. - The rejected stored chunk shapes get one test per error case. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(array): store the upgrade of the current stored document before writing A handle read from an upgraded document upserts the upgrade of what the store holds on its first non-empty chunk write: a stale handle no longer rolls back newer metadata, and an empty write stores nothing. consolidate_metadata does the same for each upgraded member before writing the consolidated document. Both go through two internal primitives in zarr.core.metadata.io: diff_documents compares a node's stored documents with those its metadata would store, value by value, and upsert_metadata encodes first, then stores only the documents that differ and returns the changes. The upgraded-document flag is a ClassVar set on the instance by one helper, mark_upgraded, which also warns; the upgrades are keyed by Zarr format; the Metadata.to_dict and V2 from_dict changes are reverted. _append goes through AsyncArray.setitem and _setitem is removed. A chunk shape that is not a list or tuple is rejected as a whole, and every expand_rle error names its dimension. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test: prefer zero-length axes for stored chunk size 0 in the lifecycle machine An empty write stores no metadata, so it no longer ends the legacy state. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(metadata): keep accepting the chunk sizes zarr 3.4.0 accepted in metadata constructors (patch release) Nothing in a patch release may reject a chunk size that zarr 3.4.0 accepted. The one chunk edge rule (`parse_chunk_edge`, which also reads RLE repeat counts) now reads any integral number as the `int` it equals: an `int`, a `bool`, a NumPy integer or an integral float, so rectilinear grids written with float edges (`[[4.0, 2]]`) read again and the grid constructors accept NumPy integers; a fractional float is still rejected. A regular chunk shape may again be any iterable. `ArrayV2Metadata(chunks=...)` and `ShardingCodec(chunk_shape=...)` read their chunk shape with `parse_shapelike`, as in 3.4.0: a scalar, NumPy integers, bools and 0 are accepted, and a 0 is written back as given (the kerchunk writer in VirtualiZarr relies on `chunks=(0,)` for empty inlined arrays). Stored documents with a chunk size of 0 are still read by the upgrades. The strict rule returns in the next minor release. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(array): leave a valid stored document as written on a stale handle's first write A handle read from an upgraded document re-reads the stored document before its first chunk write. If that document no longer needs an upgrade, store nothing: re-encoding it could differ from how another implementation wrote it, and nothing about it needs fixing. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs: describe the 4334 changes to metadata constructors for a patch release Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(metadata): read float edges only in stored rectilinear documents The patch release widened the one chunk edge rule to accept integral floats so that stored rectilinear grids written with float edges (`[[4.0, 2]]`, as zarr 3.2 wrote for float edges) keep opening. That also made a stored regular chunk shape `[10.0]` open, which zarr 3.4.0 rejected and the next minor release would reject again. The constructor rule now accepts integers of any integer type (`int`, `bool`, NumPy integers) and rejects floats. A new document upgrade reads an integral JSON float of at least 1 as an `int` where zarr 3.2 stored one: the explicit edges and run-length encoded sizes of a rectilinear chunk grid, with the standard warning. Bare sizes, repeat counts, regular chunk shapes and inner chunk shapes stay for the constructors to reject. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(codecs): pickle a ShardingCodec with an inner chunk size of 0 Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(group): build every node before create_hierarchy deletes or stores anything A node whose metadata no array or group can be built from now fails with the store untouched, even with overwrite=True. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(metadata): warn only where the user must act; guard and refresh upgraded copies - Readings that give what zarr 3.4.0 read (0/false on an empty axis, JSON true, float rectilinear edges) are silent; the metadata is still marked upgraded, so the first write re-saves it. - JSON true is read as 1 in stored rectilinear edges and RLE sizes and in nested sharding codecs' inner chunk shapes. - A write through a handle whose stored document now lays out chunks differently raises and stores nothing; with no stored document it writes as before. - Storing group metadata refreshes each upgraded consolidated member from its own stored document (the one place: save_metadata); consolidate_metadata no longer needs its own pass. - Metadata built in code with chunk size 0 is read through the upgrades, so an array can be built from it, as in 3.4.0. - Chunk edges in metadata follow the 3.4.0 integer rule (int; bool read as its value); a string or mapping is rejected as a chunk shape as a whole. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test: expect the lifecycle machine's upgrade warning only on non-empty axes Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(metadata): leave a sharded chunk size of 0 unread when the inner shape is invalid A stored outer chunk size of 0 of a sharded array is read in multiples of the inner chunk size. When that inner size is itself 0 or `false`, the unit is unknown: the upgrade now leaves the 0 for the constructor, which rejects it with the same `ValueError` zarr 3.4.0 raised, instead of a ZeroDivisionError. `_read_codec` now matches the sharding codec like `_inner_chunk_shape` does. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * perf(metadata): read each upgraded member once, concurrently, and adopt it A group handle kept the consolidated copies of upgraded members flagged, so every later group write re-read every such member, one after another, and read each twice on the first write (once to parse, once to diff). - `save_metadata` returns the metadata it stored; `AsyncGroup._save_metadata` (attrs, `update_attributes`, `delitem`, `consolidate_metadata`) and `Group.update_attributes_async` adopt it, so later writes read no member. - The refresh visits only nested groups and flagged members, and reads them with one `asyncio.gather`. The documents it reads are the ones the upsert diffs against (`read_documents` + `upsert_metadata(..., stored)`), and the array write path does the same. - `parse_stored_array` (documents -> silently marked metadata) replaces `read_stored_array`'s `(metadata, bool)` tuple, and is the one "read, mark, don't warn" path, also for code-built metadata. - A flagged member whose own document is gone or cannot be read (invalid, replaced by a group) keeps its consolidated copy instead of failing every group write. - `parse_array_metadata` of a metadata object reads it as a stored document only when `ArrayV2Metadata.chunks` holds a 0, the one chunk size that constructors still accept and the upgrades change. This removes the per-construction `to_dict` + upgrade (AsyncArray() back to 3.4.0 speed) and building arrays from codec configurations holding NumPy scalars works again, as in 3.4.0. - `create_hierarchy` documents that it stores a group's consolidated metadata as given. - Tests: second group write reads no member; nested member refresh; member without a readable document; NumPy-scalar codec configuration; stale handle whose inner chunk shape alone changed (kills `_chunk_layout` returning only the outer grid). Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(group): adopt refreshed consolidated members in place A group write replaced the handle's metadata with a copy holding the consolidated members it read again, so the handle no longer shared its consolidated dicts with subgroup handles taken earlier: an array deleted through such a subgroup was stored again by the parent's next write, and reappeared on reopen. `_refresh_consolidated` now returns, along with the copy it encodes, the members it replaced (with the consolidated dict that holds each), and `save_metadata` writes them back into those dicts once the store succeeds, unless the member was deleted or replaced meanwhile. `save_metadata` returns nothing again, and the group callers keep their metadata objects. A failed store leaves the members flagged, so a retry reads them again. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(metadata): raise the rectilinear flag error when refreshing a consolidated member A group write reads each upgraded consolidated member again from its own document, and kept the consolidated copy when that document could not be read. That also swallowed the rectilinear chunks flag error, so a member whose document now declares a rectilinear grid had its stale copy stored as valid. The flag error is now `RectilinearChunksDisabledError`, a `ValueError`, and the refresh lets it propagate: the group write raises and stores nothing. Unreadable documents keep their consolidated copy as before. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(group): store a group's documents only; keep upgraded members as stored Group writes (attributes, `update_attributes`, deleting a member, `consolidate_metadata`, `create_hierarchy`) read each upgraded member of the consolidated metadata again from its own document and stored its upgrade. Those member writes raced concurrent deletions: two concurrent `delitem`s on a consolidated group recreated a deleted array's metadata document in most runs, which zarr 3.4.0 never did. A group write now stores only the group's own documents and reads none. Array metadata read from a document that had to be upgraded keeps that document (`_stored_document`, set by `mark_upgraded`, replacing the `_stored_document_upgraded` flag), and consolidated metadata stores such a member as it was stored. Every reader of the consolidated metadata then reads the member as upgraded again, and the array's own first chunk write stores the upgrade of its current document (or refuses a changed chunk grid) as before: the only write that upgrades a member document. Removed: the refresh and adoption of consolidated members in `save_metadata` (`_refresh_consolidated`, `_refresh_array`, `_Refreshed`), and `Group.update_attributes_async`'s detour through `save_metadata`. Tests pinning the refresh are replaced by tests that a group write reads nothing and writes only the group's documents, stores the member's consolidated copy byte for byte as stored, that concurrent deletions leave no member, and that the first write through consolidated metadata stores the member's upgrade or refuses a changed grid. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs(group): say what consolidated metadata stores for an upgraded array Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(array): clear the stored document whenever an array stores its metadata Setting attributes of an array read from a document that had to be upgraded stored the upgraded document with the new attributes, but left the metadata marked with the document it was read from. A consolidated group handle shares that metadata, so its next write stored the old document in the consolidated metadata and the new attributes were lost from it (zarr 3.4.0 kept them). Every write of an array's own documents (creating, resizing, setting attributes) now goes through `AsyncArray._save_metadata`, which clears the mark afterwards, as the first chunk write does after storing the upgrade. Both clear it through `_stored_document_replaced`, the one place that declares it: the first chunk write clears it also when it stores nothing (the store already holds a valid document, or none), so it cannot be folded into the save. The deep copy in `mark_upgraded` stays: the metadata's attributes share objects with the document it was read from, which the caller also holds. A test pins it. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(metadata): pin that a failed metadata save keeps the stored document mark Setting attributes on or resizing an array read from a document that needed an upgrade clears the `_stored_document` mark only after the store accepts the new metadata. A test now injects a store failure for the array's own document and checks the mark and the stored bytes survive, for Zarr formats 2 and 3. The `_save_metadata` docstring now says only what the method does. Assisted-by: ClaudeCode:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(metadata): read a stored chunk size of 0 as 1, however long the axis A stored chunk size of 0 or `false` was read as one chunk spanning the axis at open time. On an axis that grew after the size was written, that made the chunk size depend on when the array was opened, and it could be very large: `chunks: [0, 100, 100]` on shape (10000, 100, 100) read as one 800 MB chunk. It is now read as the smallest valid chunk edge length (1, or the inner chunk size for a shard), which is what `chunks=-1` gives on a zero-length axis. A resize by software that kept the stored 0 no longer changes the layout a stale handle expects. Assisted-by: ClaudeCode:claude-opus-5-5 * fix(metadata): re-save only upgrades that move chunks, and read non-JSON input as is A stored `true` chunk size or an integral float edge is read as the value zarr already read it as, so chunks written under the upgraded metadata are where every reader looks. Marking such documents for re-saving turned a plain chunk write into a metadata write: in a ZipStore that adds a second `zarr.json` entry (a `UserWarning`, an error under `-W error`), and it opened a race with concurrent metadata writes that 3.4.0 did not have. Each upgrade now reports whether it moves chunks, and only those mark the metadata. The upgrades also detected changes by comparing JSON encodings, so `ArrayV3Metadata.from_dict` given metadata built in code (a codec instance, a NumPy integer in a sharding codec's `chunk_shape`) raised `TypeError`. Changes are now tracked where they are made. Assisted-by: ClaudeCode:claude-opus-5-5 * fix(metadata): recommend recreating an array whose stored chunk size was 0 The warning for a stored chunk size of 0 on an axis of positive length now says that the array holds only its fill value, so recreating it with the wanted chunk shape loses nothing, and gives the re-save as the way to keep it instead. A re-save freezes the smallest chunk size into an array that holds no data yet. Each reading now carries its own advice, so mark_upgraded appends no shared hint. Assisted-by: ClaudeCode:claude-fable-5-1 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(metadata): give the recipe for recreating an array read from a stored chunk size of 0 The warning names the call, zarr.from_array(array.store, name=array.path, data=array, chunks=..., overwrite=True, write_data=False), which keeps the data type, fill value, attributes and codecs, and a test pins the recipe on both formats. Assisted-by: ClaudeCode:claude-fable-5-1 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * refactor(metadata): call the lenient readings of stored documents repairs, not upgrades The module is zarr.core.metadata.repair: repair_array_document, mark_repaired, ARRAY_REPAIRS and the Repair type, AsyncArray._store_repaired_document, and the test module test_repair.py. A reading that turns an invalid stored document into a valid one fixes it; it does not move it to a newer format. Assisted-by: ClaudeCode:claude-fable-5-1 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
1 parent d18fb50 commit a9370dd

20 files changed

Lines changed: 2841 additions & 325 deletions

‎Justfile‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -57,7 +57,7 @@ coverage-serve *args:
5757

5858
# Run slow Hypothesis tests and write coverage.xml
5959
hypothesis *args:
60-
hatch run {{ quote(hatch_env) }}:coverage run --source=src -m pytest -nauto --run-slow-hypothesis tests/test_properties.py tests/test_store/test_stateful* "$@"
60+
hatch run {{ quote(hatch_env) }}:coverage run --source=src -m pytest -nauto --run-slow-hypothesis tests/test_properties.py tests/test_store/test_stateful* tests/test_array_stateful.py "$@"
6161
hatch run {{ quote(hatch_env) }}:coverage xml
6262

6363
# Validate executable documentation code blocks

‎changes/4334.bugfix.md‎

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
A chunk edge length is now always at least 1, while an array extent may be 0. Every spelling of one chunk spanning an axis (`chunks=-1`, `chunks=False`, `chunks="auto"`, `shards=-1`, `shards=False`) gives chunk size 1 on a zero-length axis, and a shard spanning an axis is a multiple of the inner chunk size, so `shards=-1` no longer fails when the axis length is not a multiple of it. Rectilinear chunk grids can be created on a zero-length dimension with a non-empty list of positive chunk sizes, which are kept for later growth.
2+
3+
`FixedDimension(size=0, ...)` now raises a `ValueError`. `ArrayV2Metadata(chunks=(0,))` is still accepted and written as given; an array built from such metadata (with `create_hierarchy`, for example) reads the chunk size as a stored chunk size of 0 is read (below). `create_hierarchy` now builds every array and group before it deletes or stores anything, so a node that cannot be built fails with the store untouched. The regular chunk grid metadata class reads a `bool` chunk edge length as the `int` it equals, and rejects a string or a mapping as a chunk shape as a whole. `RectilinearChunkGridMetadata`, which is experimental, now reads a `bool` edge length as the `int` it equals and rejects a NumPy integer or a float edge length such as `4.0` with a `TypeError`; it used to keep them as given, so that it could not store a NumPy integer, could not read back a `bool`, and stored a float as a JSON float, which the Zarr specification does not allow.
4+
5+
Stored metadata with a regular chunk size of 0 or JSON `false` (Zarr format 2 `chunks`, Zarr format 3 `regular` `chunk_shape`) is now read as chunk size 1 (the inner chunk size for sharded arrays, which previously failed to open), however long the axis is: that is the chunk size `chunks=-1` gives on a zero-length axis, and it does not depend on how far the axis has grown since. zarr-python wrote such sizes for arrays created with a zero-length axis until 3.4, and, from 2.18.7 to 3.2.1, for an explicit chunk size of 0 or `False` on an axis of any length, as in `chunks=(0,)` (those arrays could store no data). On a zero-length axis this opens silently, as before, and appending to it stores chunks of size 1. On an axis of positive length it opens with a `ZarrUserWarning`, which says that the array holds only its fill value, so that recreating it with the wanted chunk shape loses nothing (`zarr.from_array(array.store, name=array.path, data=array, chunks=..., overwrite=True, write_data=False)` keeps its data type, fill value, attributes and codecs), and how to keep it by storing valid metadata instead: `array.update_attributes({})`, then `zarr.consolidate_metadata` if the metadata is consolidated. JSON `true`, as zarr-python 3.0 and 3.2 wrote for a chunk size of `True`, is read as 1, silently, in the chunk grid (regular, and the explicit edges and run-length encoded sizes of a rectilinear one) and in the inner chunk shape of every sharding codec, nested or not. A stored rectilinear chunk grid whose edge lengths are integral JSON floats (`[[4.0, 2]]`), as zarr-python 3.2 wrote for float edges, is read with those edges as integers, silently; a float anywhere no release wrote one (a regular chunk shape, the inner chunk shape of a sharding codec, a run-length repeat count, an edge below 1) is rejected.
6+
7+
Writing data to an array whose stored metadata holds a regular chunk size of 0 or `false` (other than an empty selection) first stores the repair of the metadata the store then holds, unless another writer has stored valid metadata since, so that other readers find the chunks written (a `true` chunk size or an integral float edge is read as the value it equals, so a write stores no metadata for it); in a `ZipStore` this adds a second entry for the metadata document, as every metadata update does. If the metadata the store then holds lays out chunks differently (another writer stored a different chunk size since, say), the write raises a `ValueError` asking to reopen the array, and stores nothing. Apart from the array's own metadata writes (`update_attributes`, `resize`), which store the repair as before, this is the only operation that stores it: a group's consolidated metadata keeps such an array's metadata as it was stored (`zarr.consolidate_metadata` copies it as the array's own document holds it) until the array stores its repair through the group's handle, and changing a group reads and writes no metadata of its members.

‎docs/user-guide/arrays.md‎

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -707,6 +707,12 @@ z.append(np.arange(10, dtype='float64'))
707707
print(f"After append: shape={z.shape}, chunk_sizes={z.write_chunk_sizes}")
708708
```
709709

710+
A rectilinear array can also be created with a zero-length dimension: because no
711+
non-empty list of positive chunk sizes can sum to 0, the chunk sizes given for such a
712+
dimension are stored as-is and describe the chunks the dimension will grow into
713+
on `append` or `resize` — the same state as resizing an existing rectilinear
714+
dimension down to 0.
715+
710716
### Compressors and filters
711717

712718
Rectilinear arrays work with all codecs — compressors, filters, and checksums.

‎src/zarr/core/_json.py‎

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -41,6 +41,12 @@ def buffer_to_json(buffer: Buffer) -> JSON:
4141
return cast("JSON", json.loads(buffer.to_bytes()))
4242

4343

44+
def json_equal(a: JSON, b: JSON) -> bool:
45+
"""Whether two JSON values have the same JSON encoding. Python compares `True` and
46+
`1`, or `1.0` and `1`, as equal; JSON does not."""
47+
return json.dumps(a) == json.dumps(b)
48+
49+
4450
def buffer_to_json_object(buffer: Buffer) -> dict[str, JSON]:
4551
"""Parse the contents of a `Buffer` as a JSON object (a `dict`).
4652

‎src/zarr/core/array.py‎

Lines changed: 91 additions & 83 deletions
Original file line numberDiff line numberDiff line change
@@ -118,7 +118,14 @@
118118
ArrayV2MetadataDict,
119119
ArrayV3Metadata,
120120
)
121-
from zarr.core.metadata.io import save_metadata, save_new_metadata
121+
from zarr.core.metadata.io import (
122+
ARRAY_DOCUMENTS,
123+
parse_stored_array,
124+
read_documents,
125+
save_metadata,
126+
save_new_metadata,
127+
upsert_metadata,
128+
)
122129
from zarr.core.metadata.v2 import (
123130
CompressorLikev2,
124131
get_object_codec_id,
@@ -201,13 +208,22 @@ def _chunk_sizes_from_shape(
201208
return tuple(result)
202209

203210

204-
def parse_array_metadata(data: Any) -> ArrayMetadata:
211+
def parse_array_metadata(data: Any, path: str | None = None) -> ArrayMetadata:
212+
"""Array metadata from a metadata object or a metadata document, naming the array at
213+
`path` in warnings about how an invalid document was read.
214+
215+
`ArrayV2Metadata` accepts a chunk size of 0, as it always has, though only an
216+
invalid document holds one: such metadata is read as the documents it would store
217+
are (see `zarr.core.metadata.repair`), so an array can be built from it. No data
218+
was read or written under that chunk size, so the reading is silent."""
219+
if isinstance(data, ArrayV2Metadata) and 0 in data.chunks:
220+
return parse_stored_array(data.to_buffer_dict(default_buffer_prototype()), 2)
205221
if isinstance(data, ArrayMetadata):
206222
return data
207-
elif isinstance(data, dict):
223+
if isinstance(data, dict):
208224
zarr_format = data.get("zarr_format")
209225
if zarr_format == 3:
210-
meta_out = ArrayV3Metadata.from_dict(data)
226+
meta_out = ArrayV3Metadata.from_dict(data, path=path)
211227
if len(meta_out.storage_transformers) > 0:
212228
msg = (
213229
f"Array metadata contains storage transformers: {meta_out.storage_transformers}."
@@ -216,7 +232,7 @@ def parse_array_metadata(data: Any) -> ArrayMetadata:
216232
raise ValueError(msg)
217233
return meta_out
218234
elif zarr_format == 2:
219-
return ArrayV2Metadata.from_dict(data)
235+
return ArrayV2Metadata.from_dict(data, path=path)
220236
else:
221237
raise ValueError(f"Invalid zarr_format: {zarr_format}. Expected 2 or 3")
222238
raise TypeError # pragma: no cover
@@ -388,7 +404,7 @@ def __init__(
388404
store_path: StorePath,
389405
config: ArrayConfigLike | None = None,
390406
) -> None:
391-
metadata_parsed = parse_array_metadata(metadata)
407+
metadata_parsed = parse_array_metadata(metadata, str(store_path))
392408
config_parsed = parse_array_config(config)
393409

394410
object.__setattr__(self, "metadata", metadata_parsed)
@@ -745,7 +761,7 @@ def from_dict(
745761
ValueError
746762
If the dictionary data is invalid or incompatible with either Zarr format 2 or 3 array creation.
747763
"""
748-
metadata = parse_array_metadata(data)
764+
metadata = parse_array_metadata(data, str(store_path))
749765
return cls(metadata=metadata, store_path=store_path)
750766

751767
@classmethod
@@ -1590,10 +1606,54 @@ async def get_coordinate_selection(
15901606
return out_array
15911607

15921608
async def _save_metadata(self, metadata: ArrayMetadata, ensure_parents: bool = False) -> None:
1593-
"""
1594-
Asynchronously save the array metadata.
1595-
"""
1609+
"""Store `metadata` as this array's own documents, then clear the
1610+
`_stored_document` mark (see `_stored_document_replaced`)."""
15961611
await save_metadata(self.store_path, metadata, ensure_parents=ensure_parents)
1612+
self._stored_document_replaced()
1613+
1614+
def _stored_document_replaced(self) -> None:
1615+
"""Record that the store no longer holds a document of this array that needs an
1616+
repair: it holds the repair, a valid document, or none. The metadata this handle
1617+
holds, which a consolidated group handle may share, then stops standing for the
1618+
document it was read from (see `mark_repaired`), so no later write through either
1619+
handle stores that document again."""
1620+
object.__setattr__(self.metadata, "_stored_document", None)
1621+
1622+
async def _store_repaired_document(self) -> None:
1623+
"""Store the repair of this array's current stored document, if it needs one,
1624+
before chunks are written under this handle's metadata.
1625+
1626+
Only for metadata read from a document whose repair moves chunks (see
1627+
`zarr.core.metadata.repair`). The document is read again, because the store may
1628+
hold a newer one than this handle's metadata. If that one lays out chunks
1629+
differently (another writer stored a different chunk size since), this handle
1630+
would write chunks no reader finds, so it raises and stores nothing. If it needs
1631+
no repair (the array was re-saved since, possibly by another implementation), it
1632+
is left as written; if there is none, there is nothing to repair.
1633+
1634+
Storing the same repair twice is harmless, so handles that write chunks
1635+
concurrently need no coordination. The read and the store are not one atomic
1636+
step, though: a metadata write by another handle between them (a resize, an
1637+
attribute update) is replaced by the repair of the document read before it, as
1638+
with any two metadata writes that race.
1639+
"""
1640+
if self.metadata._stored_document is None:
1641+
return
1642+
zarr_format = self.metadata.zarr_format
1643+
documents = await read_documents(self.store_path, ARRAY_DOCUMENTS[zarr_format])
1644+
try:
1645+
current = parse_stored_array(documents, zarr_format)
1646+
except ArrayNotFoundError:
1647+
pass
1648+
else:
1649+
if _chunk_layout(current) != _chunk_layout(self.metadata):
1650+
raise ValueError(
1651+
f"The metadata stored for the array at {str(self.store_path)!r} has "
1652+
"changed since this array was opened: reopen the array to write to it."
1653+
)
1654+
if current._stored_document is not None:
1655+
await upsert_metadata(self.store_path, current, documents)
1656+
self._stored_document_replaced()
15971657

15981658
async def _set_selection(
15991659
self,
@@ -1603,6 +1663,10 @@ async def _set_selection(
16031663
prototype: BufferPrototype,
16041664
fields: Fields | None = None,
16051665
) -> None:
1666+
if product(indexer.shape) > 0:
1667+
# Chunks are about to be stored under the repaired metadata, so store it
1668+
# first: every reader of the store then agrees with them.
1669+
await self._store_repaired_document()
16061670
return await _set_selection(
16071671
self.store_path,
16081672
self.metadata,
@@ -1654,16 +1718,10 @@ async def setitem(
16541718
- This method is asynchronous and should be awaited.
16551719
- Supports basic indexing, where the selection is contiguous and does not involve advanced indexing.
16561720
"""
1657-
return await _setitem(
1658-
self.store_path,
1659-
self.metadata,
1660-
self.codec_pipeline,
1661-
self.config,
1662-
self._chunk_grid,
1663-
selection,
1664-
value,
1665-
prototype=prototype,
1666-
)
1721+
if prototype is None:
1722+
prototype = default_buffer_prototype()
1723+
indexer = BasicIndexer(selection, shape=self.metadata.shape, chunk_grid=self._chunk_grid)
1724+
return await self._set_selection(indexer, value, prototype=prototype)
16671725

16681726
@property
16691727
def oindex(self) -> AsyncOIndex[T_ArrayMetadata]:
@@ -4824,6 +4882,16 @@ async def create_array(
48244882
)
48254883

48264884

4885+
def _chunk_layout(
4886+
metadata: ArrayMetadata,
4887+
) -> tuple[tuple[int, ...] | ChunkGridMetadata, tuple[int, ...] | None]:
4888+
"""How an array's chunks are laid out: its chunk grid and, if it is sharded, the
4889+
inner chunk shape."""
4890+
grid = metadata.chunks if isinstance(metadata, ArrayV2Metadata) else metadata.chunk_grid
4891+
sharding = _sharding_codec(metadata)
4892+
return grid, None if sharding is None else sharding.chunk_shape
4893+
4894+
48274895
def _sharding_codec(metadata: ArrayMetadata) -> ShardingCodec | None:
48284896
"""The array's sharding codec, or None if the array is not sharded.
48294897
@@ -5805,58 +5873,6 @@ async def _set_selection(
58055873
)
58065874

58075875

5808-
async def _setitem(
5809-
store_path: StorePath,
5810-
metadata: ArrayMetadata,
5811-
codec_pipeline: CodecPipeline,
5812-
config: ArrayConfig,
5813-
chunk_grid: ChunkGrid,
5814-
selection: BasicSelection,
5815-
value: npt.ArrayLike,
5816-
prototype: BufferPrototype | None = None,
5817-
) -> None:
5818-
"""
5819-
Set values in the array using basic indexing.
5820-
5821-
Parameters
5822-
----------
5823-
store_path : StorePath
5824-
The store path of the array.
5825-
metadata : ArrayMetadata
5826-
The array metadata.
5827-
codec_pipeline : CodecPipeline
5828-
The codec pipeline for encoding/decoding.
5829-
config : ArrayConfig
5830-
The array configuration.
5831-
chunk_grid : ChunkGrid
5832-
The chunk grid.
5833-
selection : BasicSelection
5834-
The selection defining the region of the array to set.
5835-
value : npt.ArrayLike
5836-
The values to be written into the selected region of the array.
5837-
prototype : BufferPrototype or None, optional
5838-
A prototype buffer that defines the structure and properties of the array chunks being modified.
5839-
If None, the default buffer prototype is used.
5840-
"""
5841-
if prototype is None:
5842-
prototype = default_buffer_prototype()
5843-
indexer = BasicIndexer(
5844-
selection,
5845-
shape=metadata.shape,
5846-
chunk_grid=chunk_grid,
5847-
)
5848-
return await _set_selection(
5849-
store_path,
5850-
metadata,
5851-
codec_pipeline,
5852-
config,
5853-
chunk_grid,
5854-
indexer,
5855-
value,
5856-
prototype=prototype,
5857-
)
5858-
5859-
58605876
async def _resize(
58615877
array: AsyncArray[ArrayV2Metadata] | AsyncArray[ArrayV3Metadata],
58625878
new_shape: ShapeLike,
@@ -5906,7 +5922,7 @@ async def _delete_key(key: str) -> None:
59065922
)
59075923

59085924
# Write new metadata
5909-
await save_metadata(array.store_path, new_metadata)
5925+
await array._save_metadata(new_metadata)
59105926

59115927
# Update metadata and chunk_grid (in place)
59125928
object.__setattr__(array, "metadata", new_metadata)
@@ -5971,15 +5987,7 @@ async def _append(
59715987
slice(None) if i != axis else slice(old_shape[i], new_shape[i])
59725988
for i in range(len(array.shape))
59735989
)
5974-
await _setitem(
5975-
array.store_path,
5976-
array.metadata,
5977-
array.codec_pipeline,
5978-
array.config,
5979-
array._chunk_grid,
5980-
append_selection,
5981-
data,
5982-
)
5990+
await array.setitem(append_selection, data)
59835991

59845992
return new_shape
59855993

@@ -6006,7 +6014,7 @@ async def _update_attributes(
60066014
array.metadata.attributes.update(new_attributes)
60076015

60086016
# Write new metadata
6009-
await save_metadata(array.store_path, array.metadata)
6017+
await array._save_metadata(array.metadata)
60106018

60116019
return array
60126020

0 commit comments

Comments
 (0)