[Bug]: verify snapshot crashes on null/wrong-type integrity.tables/assets instead of exit 2

[VARUN3WARE]

Version or commit

957c9b1

Environment

Linux x86_64, Python via uv; library + CLI repro

Minimal reproduction

On main @ 957c9b1, verify_dataset_snapshot flattens receipt entries with:

# src/hflow/snapshot.py ~997–1002
*integrity.get("tables", {}).values(),
*integrity.get("assets", []),

.get(key, default) does not apply when the key is present with JSON null, so a hand-edited (or tampered) format.json crashes before the typed entry parser runs.

1. Export a normal references-mode snapshot (any one-episode catalog + manifest).
2. Edit format.json so integrity.tables is null (leave a plausible content_id / assets):

"integrity": {
  "content_id": "<any 64-hex or the original>",
  "tables": null,
  "assets": []
}

3. Run:

uv run hflow verify snapshot <snapshot-dir>
# or: verify_dataset_snapshot(<snapshot-dir>)

Observed: AttributeError: 'NoneType' object has no attribute 'values' (traceback). The CLI only catches ValueError / path errors (src/hflow/cli.py ~1526–1529), so this is not exit 2.

Same class of crash:

Mutation	Observed
"tables": null	AttributeError (.values)
"assets": null	TypeError (spread non-iterable)
"tables": []	AttributeError (list has no .values)

Related (optional same fix): "assets": {} iterates object keys as fake entries and can surface a confusing content_id mismatch instead of “assets must be a JSON array”.

Not covered by the current open board (issues): #573, #568, #567, #565, #545 (PR #574), #528, #498, #491 (PR #517), #481 (PR #542), #287, #246. Same verify/receipt family as shipped #457 / #469 / #473 / #489, but this .get/.values() hole was never pinned.

Expected behavior

Malformed integrity.tables / integrity.assets container types (null, array-where-object, object-where-array) raise ValueError with a clear message (CLI exit 2), matching the docstring’s “refuse bad receipt shapes at the boundary” contract and the per-entry _parse_file_integrity_record style. No AttributeError/TypeError traceback.

Actual behavior

Present-but-null (or wrong-type) containers bypass the default and crash inside the flatten listcomp. Recipients / CI see an unhandled exception instead of a clean unreadable-input exit.

Additional context

Definition of done

• Before flattening, require integrity.tables to be a JSON object and integrity.assets to be a JSON array (missing key may keep today’s default empty object/list); otherwise ValueError.
• hflow verify snapshot returns exit 2 with a short message (no traceback) for those shapes.
• Tests in tests/test_snapshot_verify.py (or sibling): tables: null, assets: null, tables: [] (and optionally assets: {}).

Non-goals

• Changing how a healthy export writes receipts.
• Redesigning exit 3 unverifiable vs exit 2 for a wholly non-object integrity value (can be a follow-up; today integrity: [] reports no-receipt / exit 3).
• LeRobot verify / Hub pagination ([Bug]: LeRobot importer consumes only the first page of the Hub tree listing - datasets with >1000 episode metadata files silently import a halved corpus and report success #573).

[kstonekuan]

Confirmed at snapshot.py:1000-1001. .get(key, default) returns the default only when the key is absent, so an explicit null reaches .values() and *-unpacking with no typed parse in between.

The boundary parser below it is the right shape; this is just two values reaching it unparsed. Worth covering "assets": {} in the same pass, since iterating an object's keys as entries is the confusing-failure version of the same gap.