Skip to content

Tolerate mdio-python 1.x stores on open; report missing store clearly - #179

Open
thiago-carneiro wants to merge 4 commits into
TGSAI:mainfrom
thiago-carneiro:feat/open-robustness
Open

thiago-carneiro wants to merge 4 commits into
TGSAI:mainfrom
thiago-carneiro:feat/open-robustness

Conversation

@thiago-carneiro

Copy link
Copy Markdown
Contributor

Fixes #177

Summary

Two robustness fixes in the open path, driven by real interop failures with
stores written by mdio-python 1.x (see #177):

  1. Missing-store detection — zarr::DetectVersion previously defaulted to
    ZarrVersion::kV2 when a path had no version markers at all (neither
    zarr.json nor .zgroup). The wrong default surfaced downstream as a
    confusing .zmetadata parse error. It now fails with
    not an MDIO store or path does not exist: <path>.

  2. Tolerate missing informational dataset metadata — mdio-python 1.x
    to_mdio writes none of name / apiVersion / createdOn, so opening
    such a store was rejected outright. These fields are purely informational:
    the read path now warns (ABSL_LOG(WARNING)) and continues, while the
    create path (from_json -> Construct -> validate_dataset) keeps
    requiring them. Stores carrying the v0 marker (api_version) are skipped
    from the warning — they are rejected downstream with their dedicated v0
    error, and a metadata warning there would only mislead.

Changes

  • mdio/zarr/zarr_driver.h: no silent V2 fallback; the error carries the store path.
  • mdio/dataset.h: kInformationalDatasetFields + WarnOnMissingDatasetMetadata()
    wired into the open path.
  • Documentation corrected: earlier wording claimed mdio-python writes these
    fields; it does not.

Testing

  • New: openNonExistentPathReportsMissingStore, openV3WithoutDatasetMetadata,
    openV3WithDatasetMetadata, createSpecWithoutDatasetMetadataIsRejected.
  • Full suite: 14/14 test binaries pass, including the acceptance suite
    (fill-value parity, xarray and multidimio compatibility) against
    mdio-python 1.2.3.
  • clang-format 18 applied to touched files.

DetectVersion defaulted to V2 when a path had no store markers at all
(no zarr.json and no .zgroup), so opening a non-existent path fell
through to the V2 reader and surfaced as a confusing .zmetadata parse
error. Return a clear "not an MDIO store or path does not exist" error
from DetectVersion (its only caller is from_zmetadata) and propagate
detection failures there instead of silently defaulting to V2.
mdio-python 1.x to_mdio writes no name/apiVersion/createdOn in the root
metadata. The path-based Dataset::Open already opens such stores (the
schema's required fields only gate the create path via Construct), but it
did so silently; it now emits an ABSL_LOG(WARNING) naming the missing
fields. Stores carrying the v0 marker (api_version) are skipped so the
dedicated v0 rejection stays the first message. The create path keeps
rejecting creation specs without the fields, and the writer is unchanged.
mdio-python 1.x writes name/apiVersion/createdOn via its DatasetMetadata
model, so 'writes none of them' was wrong. The tolerance is unchanged:
the fields are informational and do not affect reads, so a store missing
them warns instead of failing to open.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Open path rejects mdio-python 1.x stores: informational metadata required; missing store surfaces as confusing .zmetadata error

1 participant