Skip to content

Fix HDF5 reads of absolute field paths beneath an array of structures - #103

Open
olivhoenen wants to merge 1 commit into
split85/8-fix-hdf5-delete-pathfrom
split85/9-fix-hdf5-absolute-paths
Open

olivhoenen wants to merge 1 commit into
split85/8-fix-hdf5-delete-pathfrom
split85/9-fix-hdf5-absolute-paths

Conversation

@olivhoenen

Copy link
Copy Markdown
Collaborator

Part of the split of #85 (Tests and Benchmarks for regression) into smaller, single-purpose PRs that are easier to review.

Bug fix. al_read_data lets a caller address a field from the IDS root with a leading /. On HDF5, such reads issued while an array-of-structures context was open reported existing data as absent: the dataset name lost its tensorized [] markers, and the child context's AOS indices were applied to an ancestor's dataset. HDF5Utils::resolveAbsoluteFieldPath compares the path segment by segment with the open AOS chain, rebuilds the stored dataset name, and keeps only the AOS indices that still apply. The rationale is in ADR docs/adr/0002-absolute-field-path-resolution.md. Includes the regression tests (test_hdf5_absolute_paths.cpp).

Fork history: issue yohannmarguier#65, fork PR yohannmarguier#66.

Stack position: 9/9; depends on #101 (both touch TRACEABILITY.md and tests/contract/CMakeLists.txt).

Authorship: these commits are @yohannmarguier's, cherry-picked unchanged from his fork with git cherry-pick -x, so each one keeps its original author, date and message plus a (cherry picked from commit …) link back to the fork. Only conflicts with current develop and with the new commit order were resolved.

⚠️ Please merge with "Create a merge commit" or "Rebase and merge", not "Squash and merge": squashing would attribute Yohann's commits to the person who merges.

🤖 Generated with Claude Code

`al_read_data` has always documented that a fieldpath may address a field
from the dataobject root with a prepended `/`, but `HDF5Reader::read_ND_Data`
honored only the relative half: it replaced `/` with `&` and then
unconditionally prepended the current AOS context's tensorized path, so an
already-rooted name was appended to the context it was meant to replace
(`time_slice[]&constraints&j_phi[]&&time_slice&constraints&j_phi&…`).
`H5Lexists` found nothing, the reader returned 0, and `al_plugin_read_data`
filled the caller's buffer with EMPTY_* while reporting code 0 — stored data
reported as absent, a silent wrong answer rather than an error.

Decision: an absolute path resolves **by path segment** against the AOS chain
the caller has open, cutting at the last matching AOS boundary. That answers
the two coupled questions together — which dataset name to look up (the
tensorized `[]` markers of the retained levels are kept) and which indices
still apply (only the retained levels', so a child's cursor is never applied
to an ancestor's shallower dataset, and the timed-AOS designation is dropped
with it). Recorded in docs/adr/0002-absolute-field-path-resolution.md with
the four rejected alternatives — chiefly plain de-slashing, which fixes only
root fields, and keeping the child's whole cursor, which returns a wrong
number instead of none. Segment-wise matching is the same rule ADR 0001 chose
for `al_delete_data`, for the same reason: it tells a real descendant from a
same-prefix stranger.

The resolution lives in `HDF5Utils::resolveAbsoluteFieldPath`, which reports
how many AOS levels the target still sits under; `read_ND_Data` truncates the
current indices to it. No DD-version knowledge, no schema lookup, no ABI
change. A target beyond an AOS the caller never opened has no cursor and no
schema to infer one from, so it resolves without that `[]`, is not found, and
travels the ordinary missing-data path — decided, and pinned by a test.

Scope is HDF5 reads, as issue #65 establishes: the suite writes through
relative spellings only, so it presumes nothing about writes, delete or
arraystruct opening.

Tests: Hdf5AbsoluteFieldPaths.* — both spellings of one address compared at
nonzero indices on both levels of a nested AOS (time_slice →
constraints/j_phi), for a scalar leaf, a CHAR array leaf, ancestor targets,
root targets and the operation context itself; the plugin twin
(al_plugin_read_data) asserted separately; cache/iteration stability, an
absent-data control, and the unopened-AOS limit. Ten of the thirteen fail on
the parent commit. Verified against the full suite, the Debug leg, ASan/UBSan
(no new findings) and the Python suite.

(cherry picked from commit 858a7a2)

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.

2 participants