fn get_message(pairs: &[(Value, Value)]) -> ValueExpand description
Read a control message’s decoded "msg" field.
An absent key reads as the empty map a writer should have written, not as
an error. The format requires a writer with nothing decoded — an
unparseable message type, or a recorder not decoding bodies at all — to
emit {} rather than omit the key, but requires a reader to be more
tolerant still, and this is why: event 0 is one of the types sampling MUST
NOT drop, so refusing it over a missing "msg" discards exactly the events
the format promises to keep.
How much is lost depends on how the caller drives the reader, and the worse
case is the idiomatic one. [MoqTraceReader::read_next] returns the error,
so collect::<Result<Vec<_>, _>>() — what this crate’s own tests use —
stops at the first offending event and yields none of the ones after it. A
caller that skips errors and continues loses only the offending events;
moqtap trace does that, and prints each one, so the loss was at least
visible there.
A value that is present is kept whatever its type. Recordings predating
the rule carry a text rendering of the message here — every capture-*
case in the conformance corpus is such a file — and they stay readable,
with the field simply not addressable by key.