Function decode_largest_object 

fn decode_largest_object(bytes: &[u8]) -> FieldValue

Render a draft-15 LARGEST_OBJECT (0x09) parameter value: a Group and an Object, as two varints.

Nothing has checked that the value is two varints

Drafts 17 and later give 0x09 a Location encoding: their decoders read the two varints and re-serialise them into the stored value, so what reaches their extractor is two varints by construction. Draft-15 has no such table. 0x09 is an odd Type, so KeyValuePair::decode keeps whatever length-prefixed bytes arrived, and none of decode_parameters’ four checks — duplicates, authorization tokens, varint value ranges, subscription filters — looks at 0x09. KNOWN_VERSION_SPECIFIC_PARAMETERS admits it and check_parameter_scope permits it on SUBSCRIBE_OK, so an eight-byte SUBSCRIBE_OK carrying 0x09 with an empty value reaches here.

An empty value fails the first read and a single 0x00 fails the second, which is the nastier of the two: the first varint decodes cleanly and the value looks well formed right up to the point where it is not.

What a value it cannot read renders as

The raw bytes, as fields::params and this file’s own auth_token_to_json_d15 do. Field extraction runs on a message that has already decoded, so it has no refusal to give: what a peer sent is what there is to show.