| #216 Object array fill value |
high |
Adapted to v3 vlen-bytes dtype: zarr.full(..., dtype=VariableLengthBytes(), fill_value=b"foobar") works for both formats; fill encodes as base64, no JSON TypeError. |
| #298 Follow symbolic links in DirectoryStore |
medium |
v3 LocalStore follows symlinks: symlinked an array dir into another group, members lists it and data reads through the link. |
| #605 Better error when array/store already exists |
high |
Second zarr.create now raises the dedicated, catchable zarr.errors.ContainsArrayError — exactly what was requested. |
| #962 Passing dask array leads to TypeError |
medium |
z[:] = dask_array and zarr.array(dask_array) both succeed on main; the v2 astype(order=...) path that broke is gone. |
| #1341 ValueError on empty slice after resize() with fsspec store |
high |
FsspecStore repro (create (0,), resize, read arr[0:0]/arr[1:1]) runs clean, no ValueError. |
| #1363 FSStore with simplecache fails on missing chunks |
medium |
FsspecStore.from_url("simplecache::file://...") over a sparse array reads fine, missing chunks fill. (Original used HTTP, hence medium.) |
| #1629 Arrays with padded structured datatypes fail |
medium |
The reported TypeError on assignment is gone; data roundtrips equal. Caveat: padding is packed rather than preserved. |
| #1720 omit chunks on HTTP 400 but not other errors |
medium |
v3 FsspecStore only treats FileNotFoundError-family as missing; verified a PermissionError from the fs propagates instead of NaN-filling. |
| #1795 Deserializing arrays should not trigger load_metadata |
high |
Pickled a v3 array, deleted zarr.json from the store, unpickled and read data successfully — metadata travels with the pickle. |
| #2111 updating attributes breaks zarr.json (dim separator) |
medium |
Reopen with mode="a" + update_attributes leaves every non-attributes field of zarr.json byte-identical. (Adapted from the tensorstore-written original.) |
| #2134 [v3] Structured dtype support |
medium |
The issue's exact repro roundtrips on main (shipped via zarr-developers#2874 in 3.1). Maintainers may prefer keeping it as a tracker for residual gaps (zarr-developers#3587). |
| #2174 nbytes_stored incorrect with dimension_separator="/" |
high |
Both . and / separators now report the identical full stored size (262489 vs v2's bogus 391). |
| #2201 ensure an upper bound on key range |
medium |
Untyped range tuples replaced by typed ByteRequest; hypothesis strategy clamps; oversized RangeByteRequest on a 5-byte file returns the 5 bytes, no MemoryError. |
| #2206 consolidate_metadata(zarr.Group) writes corrupted .zmetadata |
high |
Now raises TypeError: Unsupported type for store_like: 'Group' and writes nothing — the requested fail-early behavior. |
| #2322 v2/v3 metadata encode fill_value bytes differently |
high |
Both formats now encode b'X' as base64 'WA=='; the tuple-of-ints divergence is gone. |
| #2347 [v3] fixed-width unicode string support |
high |
dtype="U3" roundtrips as <U3 with metadata FixedLengthUTF32(length=3); no longer coerced to StringDType. d-v-b already noted it was fixed via zarr-developers#2874. |
| #2394 DOC: compressor kwarg should be documented |
medium |
Current create_array docstrings answer both questions asked (default behavior, valid values per zarr format). |
| #2627 default filters for v2 object dtype are wrong |
medium |
The silent wrong-default can no longer occur: dtype='O' now raises an informative ValueError requiring an explicit zarr dtype (matching what the thread favored). |
| #2699 module 'zarr.storage' has no attribute 'DirectoryStore' |
high |
The actionable ask (document the mapping) is done: docs/user-guide/v3_migration.md has the DirectoryStore → LocalStore table row; other questions answered in-thread. |
| #2706 v3 does not accept stores of type FSMap |
high |
The issue's exact snippet now works; make_store_path explicitly handles FSMap, and full write+readback through an FSMap succeeds. |
| #2773 can write v2-format data that zarr 2.x can't read |
high |
The requested firewalling exists: serializer= with zarr_format=2 raises ValueError, and v3-only compressors are rejected for v2 arrays. |
| #2792 string dtype with 0 fill value inconsistency |
high |
Exact repro now returns ['a' 'bb' '' '0' '0'] — consistent, and matches zarr-python 2.18.4 per LDeakin's in-thread reference output. |
| #2875 getitem fails when fill_value parses as ndarray |
medium |
Reconstructed the condition (complex fill stored as [re, im]) for both formats: fill parses to a scalar and reads work, no TypeError. Fixed by the zarr-developers#2874 dtype refactor. |
| #2979 broken fill_value encoding in consolidated metadata (v2) |
high |
.zmetadata now base64-encodes the bytes fill identically to .zarray (QQ== both places) and roundtrips. |
| #3005 does zarr support big-endian |
high |
>i4 create/read works for both v2 and v3 on main; the DataType.from_numpy KeyError path was replaced by the ZDType system (was blocked on zarr-developers#2874, since merged). |
| #3016 v2 stores written by v3 unreadable by zarr-python 2 (typesize) |
high |
Main writes Blosc v2 metadata without typesize; cross-version verified — a store written by main was read back correctly with actual zarr==2.18.3. |
| #3024 Zarr2→Zarr3 conversion confusion |
medium |
The confirmed from_array+resharding bug no longer reproduces (roundtrips for even and uneven shapes); the conversion-guide ask is covered by the migration CLI (zarr-developers#3257) and docs. |
| #3025 disallow numpy scalars for metadata.fill_value |
high |
The alternative d-v-b proposed in-thread shipped: metadata __eq__ compares JSON form, so two NaN-fill arrays now compare equal — the motivating problem is gone. |
| #3090 docs for dtypes |
medium |
docs/user-guide/data_types.md exists with a "List of data types" section and sits in the mkdocs nav, addressing the original ask and the navbar-prominence follow-up. |
| #3165 Quantize filter in encoding does not work |
medium |
The TypeError: Object of type type is not JSON serializable is gone; filters=[Quantize(...)] writes successfully (with a deprecation notice pointing at zarr.codecs.numcodecs.Quantize). Verified via zarr directly, not xarray. |
| #3168 disallow 0-length fixed-size data types |
high |
dtype='U0' now raises ValueError: length must be >= 1, got 0. — the exact option the author said he'd implement. |
| #3176 V2 PCodec decompression error |
high |
The issue's repro (PCodec level 12, zarr_format=2, float64 and float32) reads back clean on main. |
| #3256 Delta filter AttributeError with astype |
high |
Exact failing snippet completes cleanly; reporter also confirmed in-thread it's fixed as of 3.1.3 (numcodecs PR 766). |
| #3284 expose ZarrFormat in public API |
high |
zarr.types.ZarrFormat exists and is in __all__ — exactly the proposed submodule. |
| #3339 abstraction leakage in codec registration |
medium |
register_codec calls are now centralized in src/zarr/codecs/__init__.py (none left in the codec-defining modules); landed via zarr-developers#3376 after the issue was filed. |
| #3548 Unknown codec 'zarr.codecs.numcodecs.PCodec' |
high |
The exact xarray repro (to_zarr with serializer=PCodec(), then open_zarr) roundtrips on main with no UnknownCodecError. |
| #3588 ZipStore has no attribute '_lock' |
high |
Exact repro (store.exists() on a fresh read-mode ZipStore) returns False with no exception. |
| #3650 resize deletion of outside chunks unbounded |
medium |
The exact grow-only repro now completes instantly (_resize skips deletion when only growing). Shrinking is still unbounded, so close only if the growth case was the accepted scope. |
🤖 AI text below 🤖
To raise the signal-to-noise ratio of the zarr-python issue tracker, all 407 open issues were reviewed and sorted into "closable candidate" vs "keep". This issue collects the ~100 candidates, grouped by the kind of evidence supporting closure.
Method. Ten parallel review passes covered every open issue (body + comments). For bug reports that looked fixed, the issue's reproduction script was run against current
main(3.2.2.dev96+ga3992139c); v2-era repros were adapted to the v3 API where the complaint still translates. The bias was conservative: anything that still reproduces, or that is a live feature request/design discussion, was kept and is not listed here (a sample of re-verified still-broken issues is in the appendix). Confidence is labeled per issue — high should be safe to close on sight, medium deserves a quick human glance first.1. Verified fixed on current main (repro was run) — 38
zarr.full(..., dtype=VariableLengthBytes(), fill_value=b"foobar")works for both formats; fill encodes as base64, no JSON TypeError.LocalStorefollows symlinks: symlinked an array dir into another group,memberslists it and data reads through the link.zarr.createnow raises the dedicated, catchablezarr.errors.ContainsArrayError— exactly what was requested.z[:] = dask_arrayandzarr.array(dask_array)both succeed on main; the v2astype(order=...)path that broke is gone.(0,), resize, readarr[0:0]/arr[1:1]) runs clean, no ValueError.FsspecStore.from_url("simplecache::file://...")over a sparse array reads fine, missing chunks fill. (Original used HTTP, hence medium.)FsspecStoreonly treats FileNotFoundError-family as missing; verified aPermissionErrorfrom the fs propagates instead of NaN-filling.zarr.jsonfrom the store, unpickled and read data successfully — metadata travels with the pickle.mode="a"+update_attributesleaves every non-attributes field ofzarr.jsonbyte-identical. (Adapted from the tensorstore-written original.).and/separators now report the identical full stored size (262489 vs v2's bogus 391).ByteRequest; hypothesis strategy clamps; oversizedRangeByteRequeston a 5-byte file returns the 5 bytes, no MemoryError.TypeError: Unsupported type for store_like: 'Group'and writes nothing — the requested fail-early behavior.b'X'as base64'WA=='; the tuple-of-ints divergence is gone.dtype="U3"roundtrips as<U3with metadataFixedLengthUTF32(length=3); no longer coerced toStringDType. d-v-b already noted it was fixed via zarr-developers#2874.create_arraydocstrings answer both questions asked (default behavior, valid values per zarr format).dtype='O'now raises an informative ValueError requiring an explicit zarr dtype (matching what the thread favored).docs/user-guide/v3_migration.mdhas theDirectoryStore → LocalStoretable row; other questions answered in-thread.make_store_pathexplicitly handlesFSMap, and full write+readback through an FSMap succeeds.serializer=withzarr_format=2raises ValueError, and v3-only compressors are rejected for v2 arrays.['a' 'bb' '' '0' '0']— consistent, and matches zarr-python 2.18.4 per LDeakin's in-thread reference output.[re, im]) for both formats: fill parses to a scalar and reads work, no TypeError. Fixed by the zarr-developers#2874 dtype refactor..zmetadatanow base64-encodes the bytes fill identically to.zarray(QQ==both places) and roundtrips.>i4create/read works for both v2 and v3 on main; theDataType.from_numpyKeyError path was replaced by the ZDType system (was blocked on zarr-developers#2874, since merged).typesize; cross-version verified — a store written by main was read back correctly with actualzarr==2.18.3.from_array+resharding bug no longer reproduces (roundtrips for even and uneven shapes); the conversion-guide ask is covered by the migration CLI (zarr-developers#3257) and docs.__eq__compares JSON form, so two NaN-fill arrays now compare equal — the motivating problem is gone.docs/user-guide/data_types.mdexists with a "List of data types" section and sits in the mkdocs nav, addressing the original ask and the navbar-prominence follow-up.TypeError: Object of type type is not JSON serializableis gone;filters=[Quantize(...)]writes successfully (with a deprecation notice pointing atzarr.codecs.numcodecs.Quantize). Verified via zarr directly, not xarray.dtype='U0'now raisesValueError: length must be >= 1, got 0.— the exact option the author said he'd implement.zarr.types.ZarrFormatexists and is in__all__— exactly the proposed submodule.register_codeccalls are now centralized insrc/zarr/codecs/__init__.py(none left in the codec-defining modules); landed via zarr-developers#3376 after the issue was filed.to_zarrwithserializer=PCodec(), thenopen_zarr) roundtrips on main with no UnknownCodecError.store.exists()on a fresh read-mode ZipStore) returnsFalsewith no exception._resizeskips deletion when only growing). Shrinking is still unbounded, so close only if the growth case was the accepted scope.2. Resolved in-thread / shipped elsewhere, never closed — 26
mode='w'is documented overwrite behavior; reporter accepted ("Ah, thank you!"). Residual v2 mode-API drift superseded by the v3 rewrite.encode_chunk_key+store.exists): "It does sound likestore.existsis what we need though, thanks!"zstdis registered in zarr-developers/zarr-extensions.datatoGroup.create_array; both sync and async signatures now have it, documented. Only optional user-guide examples remain (PR zarr-developers#2890).Buffer.as_buffer_like()exists and is used by the obstore store — exactly the requested capability.Store.supports_consolidated_metadata(PR zarr-developers#3119, "Allow Stores to opt out of consolidated metadata").bug_report.ymlnow includeszarr.print_debug_info()in the reproducer template (PR zarr-developers#3087).mode='r'); TomNicholas confirmed and moved on.create_datasetno longer exists anywhere insrc/zarr. Nothing left to do.zarr.create(); dask/dask#12153 merged and released, and the reporter confirmed thecreate_arraypath produces a valid zip.3. Obsolete — targets the removed 2.x codebase/API or long-shipped plans — 32
open_*deliberately kept. Live successor discussion is zarr-developers#2466.LRUStoreCachedoesn't exist anywhere in 3.x; the one-line optimization has no target.create_dataset/object_codecAPI; on main the operation raises an informative dtype-resolution error instead.VLenArrayAPI doesn't exist in 3.x; for supported dtypes, reads verified writeable on main.zarr.save+object_codecbug; 3.x has no object-dtype support (tracked by zarr-developers#2618), so this convenience-function bug doesn't translate.PartialReadBuffer/partial_decompressmachinery; zero grep hits on main.zarr/core.pyL1995 in the 2.x codebase; module and implementation removed.getitems(on_error="omit")is gone;FsspecStore.getonly swallows a narrow configurableallowed_exceptionstuple, so errors propagate.test_hexdigest) belong to the removed 2.x suite; no test asserts compressed digests on main.copy_all; on main it's aNotImplementedErrorstub, so the specific complaint can't translate. Labeled V2.DirectoryStoreV3,_init_creation_kwargs) no longer exist in the 3.x suite.copy_all(now a stub); author never answered dstansby's 2024 follow-up.array_keys(recurse=True)API is gone; v3 traversal ismembers(max_depth=...).synchronizerkwarg is annotated "not used". The complaint is specifically about the removed API.object_codec=Pickle()path; v3 object support tracked separately in zarr-developers#2617.ABSStore/direct azure dependency.create_datasetno longer exists in src (zarr-developers#3902); the corner case cannot occur.zarr.n5exists only in EOL 2.x; reporter found a workaround in-thread ("solved the problem").list_diron node directories and never enumerates chunk keys.4. Duplicates — 2
5. Likely fixed, not fully verified — 2
PermissionErrorpropagates instead of yielding fill values. End-to-end s3/ACL path not run.Appendix: suspected-fixed issues re-verified as still broken (deliberately kept open)
These looked closable at first glance but were re-run against main and still reproduce, so they are not close candidates: #156, zarr-developers#710, zarr-developers#828, zarr-developers#1125, zarr-developers#1435, zarr-developers#1706, zarr-developers#2030, zarr-developers#2050, zarr-developers#2214, zarr-developers#2380, zarr-developers#2407, zarr-developers#2451, zarr-developers#2486, zarr-developers#2620, zarr-developers#2705, zarr-developers#2808, zarr-developers#2814, zarr-developers#2831, zarr-developers#2834, zarr-developers#2881, zarr-developers#2919, zarr-developers#2964, zarr-developers#2971, zarr-developers#3018, zarr-developers#3054, zarr-developers#3072, zarr-developers#3162, zarr-developers#3282, zarr-developers#3387, zarr-developers#3415, zarr-developers#3466, zarr-developers#3478, zarr-developers#3495, zarr-developers#3546, zarr-developers#3571, zarr-developers#3576, zarr-developers#3582, zarr-developers#3583, zarr-developers#3595, zarr-developers#3622, zarr-developers#3744, zarr-developers#3868, zarr-developers#3964, zarr-developers#3991, zarr-developers#4032, zarr-developers#4086.
Suggested process: close the ~45 high-confidence entries directly (with a short closing comment linking back here so reporters can object), and spot-check the medium ones — especially zarr-developers#2134 (may be wanted as a tracker), zarr-developers#3650 (shrink case still unbounded), and zarr-developers#2627/zarr-developers#673 (fixed-by-erroring rather than fixed-by-working).