Add KnownMagic::WebDataV1 for the spec's 0xff5dcce9b571ba42

[thedavidmeister]

Closes #187

The metadata-v1 spec magic number table lists 0xff5dcce9b571ba42 | Web data v1 among the numbers "that the tooling maintained by the authors of this document are already handling". Every other row of that fifteen-row table has a KnownMagic variant; this one did not, so KnownMagic::try_from(0xff5dcce9b571ba42u64) returned Err(UnknownMagic).

The issue's triage question was whether the table is instead stale for this crate. It is not: the row is in the spec as published today, and crates/cli/tests/cli.rs already documents this crate's magic ls output as "derived from the magic number table of the rain metadata-v1 spec". So the table is this crate's stated oracle, and one row of it was unrepresented.

What changed

• KnownMagic::WebDataV1 = 0xff5dcce9b571ba42, declared where the spec table places it (after the rain-specific numbers, before the OffchainAsset block), plus its TryFrom<u64> arm.
• Tests: test_web_data_v1 pins the prefix bytes; the enum-wide pins test_all_discriminants_pinned and test_strum_kebab_case_parse_display go from 19 to 20 entries; the magic ls exact-output pins in crates/cli/tests/cli.rs and crates/cli/tests/magic_cli.rs and the line count in crates/cli/tests/cli_dispatch.rs follow the new declaration order.

Deliberately not changed: KnownMeta and unpack_into. A Web data v1 item now decodes with a recognised magic, but unpacking it still returns UnsupportedMeta — the spec defines no payload shape for it, nothing in this repo produces or consumes one, and that is exactly the position the OffchainAsset magics are already in.

Overlap with in-flight work

#186, #188, #190, #191 and #203 all concern cbor_decode / unknown-magic handling in crates/cli/src/meta/mod.rs. This PR does not touch that file: it makes one more magic known, it does not change what happens to a magic that stays unknown, so it is orthogonal to all of them and composes with whichever lands first. #267 (issue #188) is the only one of those open right now and shares no file with this diff. The one textual conflict risk is the shared magic ls expectation lists if another PR adds or reorders a variant; those are plain list edits and rebase cleanly.

QA

• Discriminating tests: test_web_data_v1, test_all_discriminants_pinned, test_strum_kebab_case_parse_display — each fails on base by not compiling (checked origin/main out in a worktree, copied this branch's magic.rs over it and deleted only the two source lines: error[E0599]: no variant or associated item named 'WebDataV1' found for enum 'meta::magic::KnownMagic' at the three test sites). magic_ls_prints_all_known_magic_numbers (tests/cli.rs), test_magic_ls_exact_output (tests/magic_cli.rs) and test_dispatch_magic_ls (tests/cli_dispatch.rs) do compile on base and were run there with this branch's expectations: all three FAILED on base, all three pass here.
• Mutations applied: WebDataV1 = 0xff5dcce9b571ba42 → 0xff5dcce9b571ba43 → killed by test_web_data_v1, test_all_discriminants_pinned, magic_ls_prints_all_known_magic_numbers, test_magic_ls_exact_output (test_dispatch_magic_ls survives by design — it pins only the line count and the 0xff prefix). Delete the v if v == KnownMagic::WebDataV1 as u64 => Ok(KnownMagic::WebDataV1) arm → killed by test_try_from_u64_roundtrip_all. Move the variant to the end of the enum (declaration order) → killed by magic_ls_prints_all_known_magic_numbers and test_magic_ls_exact_output, unit tests unaffected as expected since they pin values, not order.
• Oracle: the metadata-v1 spec magic number table, https://github.com/rainlanguage/specs/blob/main/metadata-v1.md — | 0xff5dcce9b571ba42 | Web data v1 |. The hex literal and the web-data-v1 kebab name in every expectation come from that row, not from the implementation. The table was checked against the enum row by row: all fourteen other rows already had variants, this was the only gap.
• Category check: the issue asks one question — add a WebDataV1 variant, or declare the spec table stale. Answered by adding the variant, with the reason for not taking the stale branch stated above. No other category in the issue.

Verification

Ran the magic-related tests only (~70 agents are building on this machine, so no full local suite): cargo test --lib --test cli --test magic_cli --test cli_dispatch magic — 41 passed, 0 failed. cargo fmt --all -- --check clean.

rainix-rs / static / rs-static fails repo-wide on an unrelated rainix hook bug.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

Next included review available in 15 minutes.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: f51a992b-c0b0-44bc-a5cc-6b35652e554e

📥 Commits

Reviewing files that changed from the base of the PR and between 45ca96c and ca1ff24.

📒 Files selected for processing (5)

• crates/cli/src/meta/magic.rs
• crates/cli/src/meta/mod.rs
• crates/cli/tests/cli.rs
• crates/cli/tests/cli_dispatch.rs
• crates/cli/tests/magic_cli.rs

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thedavidmeister]

CI on the first head caught one test my local run missed: meta::tests::test_unpack_into_whitelist failed on rs-test (ubuntu and macos). That test asserts its supported + unsupported lists together cover every KnownMagic variant, so a new variant has to be named in one of them. I had run only the magic-filtered tests locally, which does not select it.

Fixed in ca1ff24 by naming WebDataV1 in the unsupported list. No behaviour change: unpack_into already returned UnsupportedMeta for it, since it is not in the unpack_into match arm — the test was simply not told about the new variant.

QA addendum for that commit:

• Discriminating test: test_unpack_into_whitelist — failed on the previous head of this PR in CI (rainix-rs / test / rs-test on both ubuntu-latest and macos-latest), passes at ca1ff24.
• Mutation applied: delete KnownMagic::WebDataV1, from the unsupported list → killed by test_unpack_into_whitelist, on the supported.len() + unsupported.len() == KnownMagic::iter().count() assertion at crates/cli/src/meta/mod.rs:1667.
• Oracle: unchanged — the spec table row | 0xff5dcce9b571ba42 | Web data v1 |. Which list the variant belongs in follows from the diff itself: unpack_into was deliberately not extended, so unsupported is the only list where the variant's actual behaviour is asserted.
• Verification, this time over the whole crate rather than a filter: cargo test -p rain-metadata --no-fail-fast under nix develop — 326 passed, 0 failed (309 lib + 17 across the integration targets).

rainix-rs / static / rs-static still fails repo-wide on the unrelated rainix hook bug.