FsspecStore.from_url() raises "RuntimeError: Loop is not running" during interpreter shutdown

[hginzel]

Zarr version

v3.3.0

Numcodecs version

v0.16.5

Python Version

3.12.11

Operating System

Ubuntu 26.04

Installation

uv add zarr

Environment

Python 3.12.11
zarr 3.3.0
fsspec 2026.7.0
adlfs 2026.5.0
azure-identity 1.25.3

Description

Creating a FsspecStore backed by Azure Blob Storage succeeds, but during
interpreter shutdown the following exception is emitted:

RuntimeError: Loop is not running

The exception is raised from weakref._exitfunc during cleanup.

Steps to reproduce

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

import zarr
from zarr.storage import FsspecStore
from azure.identity import DefaultAzureCredential

FsspecStore.from_url(
    "az://container/example.zarr",
    storage_options={
        "account_name": "<account>",
        "credential": DefaultAzureCredential(),
    },
)

print("OK")
# zarr.print_debug_info()

Additional output

Traceback (most recent call last):
  File ".../weakref.py", line ...
  ...
  File ".../fsspec/asyn.py", line 76, in sync
    raise RuntimeError("Loop is not running")
RuntimeError: Loop is not running

[d-v-b]

I believe this is a side effect of fsspec caching storage connections internally. when you close the store, fsspec doesn't know that the only user of the connection is gone, and it keeps the connection around until interpreter shutdown, and then depending on the order in which objects are reaped you see this error. that's speculation from me, @martindurant would know more.

for fixes, I think it's possible to instruct fsspec not to cache the connection. And we should probably also implement context manager behavior for stores, so resources can be formally cleaned up. Otherwise we don't want our stores to mess around with the contents of the fsspec cache.