Reading/writing causes `uns` item to change type

[lazappi]

Please make sure these conditions are met

• I have checked that this issue has not already been reported.
• I have confirmed this bug exists on the latest version of anndata.
• (optional) I have confirmed this bug exists on the main branch of anndata.

Report

When a nested list item in uns is written to disk and read back it is stored as an array.

Code:

# /// script
# requires-python = ">=3.12"
# dependencies = [
#   "anndata@git+https://github.com/scverse/anndata.git",
# ]
# ///

import anndata

adata = anndata.AnnData(uns={'spatialdata_attrs': {'instance_key': 'cell_id', 'region_key': 'region', 'region': ['cell_circles']}})

print(adata.uns["spatialdata_attrs"])

adata.write_h5ad("test.h5ad")
adata = anndata.read_h5ad("test.h5ad")

print(adata.uns["spatialdata_attrs"])

Traceback:

{'instance_key': 'cell_id', 'region_key': 'region', 'region': ['cell_circles']}
{'instance_key': 'cell_id', 'region': array(['cell_circles'], dtype=object), 'region_key': 'region'}

This example causes a downstream error in spatialdata because the array is not hashable:

  Traceback (most recent call last):
    File ".viash_script.py", line 76, in <module>
      sdata["table"] = mod
      ~~~~~^^^^^^^^^
    File "/usr/local/lib/python3.12/site-packages/spatialdata/_core/spatialdata.py", line 2343, in __setitem__
      schema = get_model(value)
               ^^^^^^^^^^^^^^^^
    File "/usr/local/lib/python3.12/site-packages/spatialdata/models/models.py", line 1259, in get_model
      return _validate_and_return(TableModel, e)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    File "/usr/local/lib/python3.12/site-packages/spatialdata/models/models.py", line 1242, in _validate_and_return
      schema.validate(e)
    File "/usr/local/lib/python3.12/site-packages/spatialdata/models/models.py", line 1116, in validate
      cls._validate_table_annotation_metadata(data)
    File "/usr/local/lib/python3.12/site-packages/spatialdata/models/models.py", line 1054, in _validate_table_annotation_metadata
      if len(set(expected_regions).symmetric_difference(set(found_regions))) > 0:
             ^^^^^^^^^^^^^^^^^^^^^
  TypeError: unhashable type: 'numpy.ndarray'

I'm not sure if this is a new thing or something else has changed (in spatialdata maybe) to cause the error.

Versions

Package	Version
anndata	0.12.10

Dependency	Version
packaging	26.0
MarkupSafe	3.0.3
google-crc32c	1.8.0
numpy	2.4.4
scanpy	1.12
session-info2	0.4.1
h5py	3.16.0
decorator	5.2.1
six	1.17.0
asttokens	3.0.1
jedi	0.19.2
Jinja2	3.1.6
fast-array-utils	1.4
PyYAML	6.0.3
traitlets	5.14.3
charset-normalizer	3.4.7
threadpoolctl	3.6.0
toolz	1.1.0
ipykernel	7.2.0
zarr	3.1.6
tblib	3.2.2
pure_eval	0.2.3
prompt_toolkit	3.0.52
debugpy	1.8.20
parso	0.8.6
pyzmq	27.1.0
msgpack	1.1.2
natsort	8.4.0
pyarrow	23.0.1
executing	2.2.1
setuptools	82.0.1
cloudpickle	3.1.2
ptyprocess	0.7.0
psutil	7.2.2
pandas	2.3.3
python-dateutil	2.9.0.post0
comm	0.2.3
xarray	2026.2.0
pytz	2026.1.post1
jupyter_core	5.9.1
wcwidth	0.6.0
scipy	1.17.1
ipython	9.12.0
Pygments	2.20.0
pexpect	4.9.0
donfig	0.8.1.post1
tornado	6.5.5
appnope	0.1.4
platformdirs	4.9.6
fsspec	2026.3.0
jupyter_client	8.8.0
numcodecs	0.16.5
stack-data	0.6.3
dask	2026.1.1
typing_extensions	4.15.0
legacy-api-wrap	1.5

Component	Info
Python	3.14.4 (main, Apr 7 2026, 13:13:20) [Clang 21.0.0 (clang-2100.0.123.102)]
OS	macOS-26.4.1-arm64-arm-64bit-Mach-O
Updated	2026-04-28 07:12

[ilan-gold]

@lazappi This is basically a rehash of #1979 I think. I would really love help with #1979 if anyone in the community (spatialdata, @LucaMarconato maybe) wanted to take it on. I think it would be simple:

1. Update our spec to add a uns h5py/zarr attribute to an empty uns group (or to the root anndata store, but this might require upgrading the entire anndata spec)
2. Create a boolean setting like anndata.settings.write_uns_as_json

This way consumers will see a breaking change in their spec readers (hopefully, because there is a new version number somewhere in the now-updated spec), and be alerted to this change.

[lazappi]

Sorry for the duplicate, I did have a look but I guess I missed it. Feel free to close this if you prefer.

I do wonder if spatialdata has some way of handling this or if somehow I ended up with weird/unexpected values? Maybe @LucaMarconato has an idea or we can move that discussion elsewhere.

[LucaMarconato]

In spatialdata, we remove the uns information from anndata and store it in zarr.json. This decision originates from our original proposal of tables as part of the NGFF spec ome/ngff#64, which stored the information in .zattrs (the Zarr v2 equivalent of zarr.json). When reading, we chose to copy the information in .uns to enhance discoverability for users, eliminating it from uns storage upon write to prevent redundant saving.

As a result, we never encountered the bug.

To move forward I would suggest we actually eliminate the metadata from uns both on-disk and in-memory, relocating it to the spatialdata level. This would mean storing it on-disk in zarr.json and in-memory in sdata.attrs (which is a dict). We worked on a prototype for this in the Padua and Venice hackathon last month.