InterpreterCallerMeta::try_from(RainMetaDocumentV1Item) ignores the item's magic, accepting a mismatched intent signal

[thedavidmeister]

Unit

crates/cli/src/meta/types/interpreter_caller/v1.rs — impl TryFrom<RainMetaDocumentV1Item> for InterpreterCallerMeta (group g5-interpretercallermeta-v1, adversarial mutation-test pass).

Intent oracle

Rain metadata-v1 spec: the per-item magic number is the "signal of intent for the payload" that tooling reads "in O(1)... without needing to first parse". A meta map's magic says what the payload is.

Violated property

InterpreterCallerMeta::try_from(item: RainMetaDocumentV1Item) never inspects item.magic. A document item tagged with any magic — e.g. KnownMagic::SolidityAbiV2 or KnownMagic::OpMetaV1 — whose payload happens to parse as InterpreterCaller JSON converts successfully into an InterpreterCallerMeta. The declared intent signal is ignored at the exact boundary whose job is to interpret it.

RainMetaDocumentV1Item::unpack_into::<T> (meta/mod.rs) does gate on magic, but only on "is this any supported magic", not "is this the magic that matches T" — so the same confusion passes through unpack_into as well, and direct TryFrom has no gate at all.

Verified repro

let item = RainMetaDocumentV1Item {
    payload: serde_bytes::ByteBuf::from(VALID_INTERPRETER_CALLER_JSON),
    magic: KnownMagic::SolidityAbiV2, // wrong intent signal
    content_type: ContentType::Json,
    content_encoding: ContentEncoding::None,
    content_language: ContentLanguage::En,
    schema: None,
};
assert!(InterpreterCallerMeta::try_from(item).is_ok()); // succeeds despite the mismatched magic

Triage framing (neutral)

This pattern is shared by the other meta types' TryFrom<RainMetaDocumentV1Item> impls, so it may be a deliberate "caller has already routed on magic" design. If so it is undocumented; if not, the conversion should reject a mismatched magic. Flagged for a decision, not adjudicated. (Scope of this run's slice is the InterpreterCaller unit; the same question likely generalises.)

[thedavidmeister]

Already fixed by open PR #242 (branch 2026-08-25-issue-165, head 5853762), which closes the near-duplicate #165. No separate PR opened; evidence below.

The gate this issue asks for is in that diff, at crates/cli/src/meta/types/interpreter_caller/v1.rs:

impl TryFrom<RainMetaDocumentV1Item> for InterpreterCallerMeta {
    type Error = Error;
    fn try_from(value: RainMetaDocumentV1Item) -> Result<Self, Self::Error> {
        if value.magic != KnownMagic::InterpreterCallerMetaV1 {
            return Err(Error::InvalidMetaMagic(
                KnownMagic::InterpreterCallerMetaV1,
                value.magic,
            ));
        }
        Self::try_from(value.unpack()?)
    }
}

Point by point against this issue:

• Verified repro — the item in the repro carries KnownMagic::SolidityAbiV2, so it now returns Err(Error::InvalidMetaMagic(InterpreterCallerMetaV1, SolidityAbiV2)) instead of Ok. gate OpMeta and InterpreterCallerMeta item conversions on magic #242's test meta::types::interpreter_caller::v1::tests::test_try_from_meta_item_rejects_wrong_magic asserts exactly that, over SolidityAbiV2, OpMetaV1 and RainMetaDocumentV1, checking the expected/actual arguments rather than just is_err().
• The unpack_into::<T> leak — unpack_into (meta/mod.rs:289) is a whitelist match that then calls T::try_from(self), so it inherits the per-type gate; unpack_into::<InterpreterCallerMeta> on a SolidityAbiV2-magic item now fails at the TryFrom. No change to unpack_into itself is needed for this issue.
• The design question in the triage framing — answered "not deliberate, gate it", consistent with the four sibling typed metas (DotrainSourceV1, OrderBuilderStateV1, RaindexSignedContextOracleV1, AuthoringMetaV2) that already gate, and using the same Error::InvalidMetaMagic(expected, actual) argument order as DotrainSourceV1/OrderBuilderStateV1.

CI evidence on #242 @ 5853762: rainix-rs / test / rs-test passes on both ubuntu-latest and macos-latest (so the new discriminating test passes), along with rs-wasm, rs-wasm-test, copy-artifacts, all three rainix-sol lanes and test. The only red check is rainix-rs / static / rs-static, which is failing repo-wide on an unrelated rainix hook bug.

Not covered by #242, and out of this issue's stated scope (the InterpreterCaller unit) — the wider generalisation the triage framing anticipates is still open for the untyped/other impls that take a RainMetaDocumentV1Item with no magic check: SolidityAbiMeta and JsonAbi (types/solidity_abi/v2.rs:61,68), AuthoringMeta v1 (types/authoring/v1.rs:162), and the String / Vec<u8> impls (meta/mod.rs:173,181, the latter deliberately magic-agnostic as the ExpressionDeployerV2BytecodeV1 alias). If that generalisation is wanted it needs its own issue and its own decision per type.

Suggested disposition: close this as fixed by #242 once #242 merges, or as a duplicate of #165 now.