-uses:actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8# v5.0.0

-name:Install uv

uses:astral-sh/setup-uv@b75a909f75acd358c2196fb9a5f1299a9a8868a4#v6.7.0

uses:astral-sh/setup-uv@2ddd2b9cb38ad8efd50337e8ab201519a34c9f24#v7.1.1

-name:Check changelog entries

run:uv run --no-sync python ci/check_changelog_entries.py

SEARCH_QUERY:'repo:zarr-developers/zarr-python is:issue created:${{ env.last_month }} -reason:"not planned"'

-name:Create issue

uses:peter-evans/create-issue-from-file@v5

uses:peter-evans/create-issue-from-file@v6

with:

title:Monthly issue metrics report

token:${{ secrets.GITHUB_TOKEN }}

default_stages:[pre-commit, pre-push]

repos:

-repo:https://github.com/astral-sh/ruff-pre-commit

rev:v0.13.1

rev:v0.13.3

hooks:

-id:ruff-check

args:["--fix", "--show-fixes"]

-hypothesis

-s3fs

-repo:https://github.com/scientific-python/cookie

rev:2025.05.02

rev:2025.10.01

hooks:

-id:sp-repo-review

-repo:https://github.com/pre-commit/pygrep-hooks

Increased the default value of`async.concurrency` from 10 to 64 to improve parallelism and throughput for concurrent I/O operations. This change enables better performance out-of-the-box for most workloads. Users with specific resource constraints or when using many Dask threads may want to lower this value via the`ZARR_ASYNC_CONCURRENCY` environment variable or by setting`zarr.config.set({'async.concurrency': N})`.

Accept`"bytes"` as an alias for`"variable_length_bytes"` when parsing`JSON`-encoded Zarr V3

data types.

Fixed a bug where the`"consolidated_metadata"` key was written to metadata documents even when

consolidated metadata was not used, resulting in invalid metadata documents.

- Add a command-line interface to migrate v2 Zarr metadata to v3. Corresponding functions are also provided under zarr.metadata. ([#1798](https://github.com/zarr-developers/zarr-python/issues/1798))

- Add obstore implementation of delete_dir. ([#3310](https://github.com/zarr-developers/zarr-python/issues/3310))

- Adds a registry for chunk key encodings for extensibility. This allows users to implement a custom`ChunkKeyEncoding`, which can be registered via`register_chunk_key_encoding` or as an entry point under`zarr.chunk_key_encoding`. ([#3436](https://github.com/zarr-developers/zarr-python/issues/3436))

- Trying to open a group at a pathwere a array already exists now raises a helpful error. ([#3444](https://github.com/zarr-developers/zarr-python/issues/3444))

- Trying to open a group at a pathwhere an array already exists now raises a helpful error. ([#3444](https://github.com/zarr-developers/zarr-python/issues/3444))

Coming soon.

Zarr is designed to support parallel computing and enables concurrent reads and writes to arrays. This section covers how to optimize Zarr's concurrency settings for different parallel computing scenarios.

Zarr uses asynchronous I/O internally to enable concurrent reads and writes across multiple chunks. The level of concurrency is controlled by the`async.concurrency` configuration setting, which determines the maximum number of concurrent I/O operations.

The default value is 64, which provides good performance for most workloads. You can adjust this value based on your specific needs:

import zarr

zarr.config.set({'async.concurrency':128})

Higher concurrency values can improve throughput when:

- Working with remote storage (e.g., S3, GCS) where network latency is high

- Reading/writing many small chunks in parallel

- The storage backend can handle many concurrent requests

Lower concurrency values may be beneficial when:

- Working with local storage with limited I/O bandwidth

- Memory is constrained (each concurrent operation requires buffer space)

- Using Zarr within a parallel computing framework (see below)

[Dask](https://www.dask.org/) is a popular parallel computing library that works well with Zarr for processing large arrays. When using Zarr with Dask, it's important to consider the interaction between Dask's thread pool and Zarr's concurrency settings.

**Important**: When using many Dask threads, you may need to reduce both Zarr's`async.concurrency` and`threading.max_workers` settings to avoid creating too many concurrent operations. The total number of concurrent I/O operations can be roughly estimated as:

For example, if you're running Dask with 10 threads and Zarr's default concurrency of 64, you could potentially have up to 640 concurrent operations, which may overwhelm your storage system or cause memory issues.

**Recommendation**: When using Dask with many threads, configure Zarr's concurrency settings:

import zarr

import dask.arrayas da

zarr.config.set({

'async.concurrency':4,# Limit concurrent async operations

'threading.max_workers':4,# Limit Zarr's internal thread pool

})

z= zarr.open_array('data/large_array.zarr',mode='r')

arr= da.from_array(z,chunks=z.chunks)

result= arr.mean(axis=0).compute()

**Configuration guidelines for Dask workloads**:

-`async.concurrency`: Controls the maximum number of concurrent async I/O operations. Start with a lower value (e.g., 4-8) when using many Dask threads.

-`threading.max_workers`: Controls Zarr's internal thread pool size for blocking operations (defaults to CPU count). Reduce this to avoid thread contention with Dask's scheduler.

You may need to experiment with different values to find the optimal balance for your workload. Monitor your system's resource usage and adjust these settings based on whether your storage system or CPU is the bottleneck.

Zarr arrays are designed to be thread-safe for concurrent reads and writes from multiple threads within the same process. However, proper synchronization is required when writing to overlapping regions from multiple threads.

For multi-process parallelism, Zarr provides safe concurrent writes as long as:

- Different processes write to different chunks

- The storage backend supports atomic writes (most do)

When writing to the same chunks from multiple processes, you should use external synchronization mechanisms or ensure that writes are coordinated to avoid race conditions.

"order":"C",

"write_empty_chunks":False,

},

"async": {"concurrency":10,"timeout":None},

"async": {"concurrency":64,"timeout":None},

"threading": {"max_workers":None},

"json_indent":2,

"codec_pipeline": {

returndata==cls._zarr_v3_name

returndatain (cls._zarr_v3_name,"bytes")

def_from_json_v2(cls,data:DTypeJSON)->Self: