AuthoringMetaV2::fetch_for_contract panic-indexes metas[0] and decoded[0], relying on other crates' non-empty guarantees

[thedavidmeister]

Unit

crates/cli/src/meta/types/authoring/v2.rs — AuthoringMetaV2::fetch_for_contract (AMT group g3-graphql-query-processing).

Intent oracle

fetch_for_contract returns Result<_, FetchAuthoringMetaV2WordError>; every failure mode in the pipeline is expressed as a wrapped error variant, so callers reasonably assume the function does not panic on remote data.

Violated property

Two unchecked indexings rely on non-emptiness guarantees that live elsewhere:

RainMetaDocumentV1Item::cbor_decode(metas[0].as_slice()).map_err(...)?[0].clone()

• metas[0] is panic-free only because MetaboardSubgraphClient::get_metabytes_by_hash (a different crate, rain-metaboard-subgraph) returns Err(Empty) for an empty result set.
• ...?[0] is panic-free only because cbor_decode rejects zero-item decodes with CorruptMeta.

Both are true today (verified by reading both call targets), so this is a latent hazard, not a current panic: any future relaxation of either invariant — or a new caller path — turns a remote-data condition into an index-out-of-bounds panic instead of a FetchAuthoringMetaV2WordError.

Verified repro

None reachable through the current dependency behaviour; this is a fragility finding backed by the cross-crate invariant trace above, flagged from the AMT survey note that marked these indexings for adversarial attention.

Triage framing

metas.first() / .get(0) with an explicit error (or documenting the invariants at the call site) would make panic-freedom local. Possibly acceptable as-is; flagging so the reliance is a recorded decision. Not adjudicating here.

[thedavidmeister]

Related: #157 covers the behavioural angle of the same two indexings (only the first meta / first cbor document is ever consulted). This issue is specifically the panic-freedom angle: both indexings avoid panics only via non-emptiness guarantees in rain-metaboard-subgraph (Empty) and cbor_decode (CorruptMeta), which live outside this function and one outside this crate.

[thedavidmeister]

Resolved by the open PR #251 (#157), not by separate work here — evidence below, verified by reading both trees rather than the PR description.

On main (45ca96c) the two indexings this issue names are the only ones in fetch_for_contract; grepping the function body for [0] / unwrap() / expect( returns exactly:

metas[0].as_slice()
})?[0]

On #251's head (cbcf6db) the same grep over the same function returns nothing. Both indexings are gone, replaced by iteration:

let mut first_error: Option<AuthoringMetaV2Error> = None;
for meta_bytes in &metas {
    let items = match RainMetaDocumentV1Item::cbor_decode(meta_bytes.as_slice()) {
        Ok(items) => items,
        Err(error) => { first_error.get_or_insert(error.into()); continue; }
    };
    for item in items {
        match AuthoringMetaV2::try_from(item) {
            Ok(meta) => return Ok(meta),
            Err(error) => { first_error.get_or_insert(error); }
        }
    }
}

Err(FetchAuthoringMetaV2WordError {
    contract_address, rpcs, metaboard_url,
    error: first_error.unwrap_or(AuthoringMetaV2Error::MetaMagicNumberMismatch),
})

This is stronger than the metas.first() / .get(0) fix the triage framing proposes: there is no non-emptiness reliance left to make local, because there is no index. Empty metas skips the outer loop; a zero-item cbor decode skips the inner loop; both fall through to the terminal Err, and the terminal is unwrap_or, not unwrap. Neither rain-metaboard-subgraph's Empty nor cbor_decode's CorruptMeta is load-bearing for panic-freedom any more — if either invariant is relaxed, the result is a FetchAuthoringMetaV2WordError, which is what the intent oracle in this issue asks for.

Writing a .get(0) fix on top would touch the identical lines and conflict with #251 for no behavioural gain, so nothing separate is being opened. Close this when #251 merges.

One carry-over to watch: #250 (#156) also rewrites fetch_for_contract, but only the RPC half — its head still has RainMetaDocumentV1Item::cbor_decode(metas[0].as_slice()).map_err(|error| wrap_error(error.into()))?[0], now inside its wrap_error closure. #250 and #251 both branch off main and both are MERGEABLE against it today, so whichever lands second resolves this conflict by hand. If that resolution takes #250's metaboard half, the hazard described here comes back and this issue should be reopened.