Skip to content

feat(zarr-metadata): add a reader that reports declarations a reader cannot open - #440

Open
d-v-b wants to merge 2 commits into
mainfrom
claude/zarr-metadata-feedback-99aa76
Open

d-v-b wants to merge 2 commits into
mainfrom
claude/zarr-metadata-feedback-99aa76

Conversation

@d-v-b

@d-v-b d-v-b commented Nov 6, 2026

Copy link
Copy Markdown
Owner

🤖 AI text below 🤖

zarr_metadata.model.read_openable_node_metadata_v3 reads a v3 zarr.json as read_node_metadata_v3 does, and also reports each declaration a reader must understand to open the node that nothing in scope claims, such as an unknown codec or an unknown top-level member without "must_understand": false, as a problem of the new kind unclaimed_declaration. Its reading has no problems exactly when a reader that understands the scope can open the node, so a validator does not have to check unclaimed_declarations itself. The other readers still accept unclaimed declarations, and the from_json and reader docstrings now point to unclaimed_declarations and the new reader.

Why

A downstream validator (refkv) reported that ZarrV3GroupMetadata.from_json({..., "extra": 1}) parses without error, while the spec requires a reader to refuse it and zarr-python does. The model accepting unclaimed declarations is deliberate (it keeps the format open, and unclaimed_declarations / must_understand_fields already list them), but nothing turned that into problems a validator can report. This adds that reader without changing the existing ones.

Changes

  • read_openable_node_metadata_v3 in model/_group_v3.py: adds one unclaimed_declaration problem per entry of unclaimed_declarations_of(reading.declarations(), waived), located where the document writes it, with that value as input; drops the model when any problem exists. Works whether or not the document has other problems. A group's consolidated_metadata entries are not read, matching read_group_metadata_v3.
  • ProblemKind gains unclaimed_declaration.
  • waived_members takes any mapping of values, so the reader can pass the members as written.
  • Docstrings of from_json and the v3 array/group readers, the zarr_metadata.model module docstring, and docs/parsing-validation.md (whose hand-written can-open snippet becomes a tested example of the new reader).
  • One parametrized test in tests/model/test_unclaimed_declarations.py over codecs (including inside a shard), unknown array and group members with and without the waiver, codecs inside a claimed member, a document with other problems, an unknown node type, and a non-object.

just check passed locally (ruff, pyright, test suite on 3.11 and the newest supported interpreter, docs build).

🤖 Generated with Claude Code

d-v-b and others added 2 commits November 6, 2026 13:32
`read_openable_node_metadata_v3` reads a v3 `zarr.json` as
`read_node_metadata_v3` does and adds a problem of the new kind
`unclaimed_declaration` for each declaration a reader must understand
that nothing in scope claims: an unknown codec, data type or chunk grid,
or an unknown top-level member without `"must_understand": false`. Its
reading has no problems exactly when a reader that understands the scope
can open the node.

The other readers keep accepting unclaimed declarations, so the format
stays open; their docstrings and the parsing guide now point to
`unclaimed_declarations` and the new reader. Prompted by refkv's report
that an unknown v3 member parses without error.

Assisted-by: ClaudeCode:claude-opus-5-5
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assisted-by: ClaudeCode:claude-opus-5-5
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant