process_deployer_query reports corrupt subgraph payloads as NoRecordFound, indistinguishable from absence

[thedavidmeister]

Unit

crates/cli/src/meta/query/mod.rs — process_deployer_query (AMT group g3-graphql-query-processing).

Intent oracle

The doc comment: "process a response for a deployer by resolving if a record was found or reject if nothing found or rejected with error" — i.e. NoRecordFound models absence. Error also carries variants that model malformed data (DecodeHexStringError, CorruptMeta).

Violated property

All eight hex-decode failures (bytecode, parser, store, interpreter, meta[0].id, deployTransaction.id, constructorMetaHash, constructorMeta) are collapsed to Error::NoRecordFound via .or(Err(Error::NoRecordFound))?, and so are all missing-field cases. A subgraph that has the record but serves corrupt hex is indistinguishable from a subgraph with no record at all; when search_deployer races several subgraphs with select_ok, a systemically corrupt record surfaces to the caller as "found no matching record".

Verified repro

meta::query::tests::test_process_deployer_query_invalid_hex_is_no_record_found (added in the AMT coverage PR) demonstrates each corrupt-hex case returning NoRecordFound; the tests pin current behaviour as-is.

Triage framing

Plausibly deliberate: within select_ok, any per-subgraph failure only needs to be non-fatal so healthier subgraphs can win, and the single variant achieves that. Flagging the diagnostic collapse (absence vs corruption) so it is a recorded choice; if distinguishing matters, a CorruptRecord-style variant would preserve the select_ok semantics while keeping the signal. Not adjudicating here.

[thedavidmeister]

Correction to the repro reference: the group's coverage landed via PR #193, where the demonstrating tests are the per-field meta::query::tests::test_process_deployer_query_invalid_*_hex_is_no_record_found family — each corrupt-hex case returns NoRecordFound, pinning the current collapse of corruption into absence.