memory:// URL scheme no longer routes to fsspec, breaking interop with MemoryFileSystem #3939

Zarr version

v3.2.0

Numcodecs version

v0.16.5

Python Version

3.13

Operating System

macOS (also reproduced on Linux in xarray's CI)

Installation

via pixi (conda-forge zarr=3.2.0)

Description

In zarr-python 3.2.0, zarr.storage._common.make_store special-cases the memory:// URL scheme to construct a ManagedMemoryStore instead of falling through to FsspecStore.from_url(...). This silently changes the meaning of memory://... URLs.

Previously, a memory://... string was treated as an fsspec URI and resolved against fsspec's process-wide MemoryFileSystem. Now it resolves to zarr's own in-process ManagedMemoryStore, which is a separate, isolated key/value store with no connection to fsspec.

As a result, the pattern of writing to fsspec's MemoryFileSystem via a mapper and then opening the resulting store via its memory://... URL is broken.

This is what make_store does in 3.2.0:

elif isinstance(store_like, str) and parsed is not None:
    if parsed.scheme == "memory":
        # Create or get a ManagedMemoryStore
        return ManagedMemoryStore(name=parsed.name, path=parsed.path, read_only=_read_only)

The previous behaviour was that, when fsspec is installed, a memory://... URL passed as a string continues to be routed through fsspec (so writers and readers using the same URL share state). If ManagedMemoryStore is the new default, then either:

• it should share state with fsspec's MemoryFileSystem, or
• the breaking change should be documented in release notes with a deprecation/warning path, and ideally an opt-in scheme (e.g. managed-memory://) so existing fsspec-backed users aren't silently broken.

Concrete impact: xarray's test_open_fsspec fails against zarr 3.2.0 with GroupNotFoundError: No group found in store 'memory://out2.zarr' at path '', even though the data is present in fsspec's MemoryFileSystem. Any downstream library doing the same write-via-mapper / read-via-URL pattern will silently read from an empty store.

Steps to reproduce

# /// script
# requires-python = ">=3.12"
# dependencies = [
#   "zarr@git+https://github.com/zarr-developers/zarr-python.git@main",
#   "fsspec",
# ]
# ///
#
# This script automatically imports the development branch of zarr to check for issues

import fsspec
import zarr

# Write a zarr group through fsspec's MemoryFileSystem
m = fsspec.filesystem("memory")
mm = m.get_mapper("out.zarr")
g = zarr.open_group(mm, mode="w", zarr_format=3)
g.attrs["hello"] = "world"

# The data is in fsspec's MemoryFileSystem
print("fsspec contents:", m.find("/"))
# -> ['/out.zarr/zarr.json']

# Reading the same data via the matching URL fails in 3.2.0
zarr.open_group("memory://out.zarr", mode="r")
# zarr.errors.GroupNotFoundError:
#   No group found in store 'memory://out.zarr' at path ''

Additional output

No response