Function serialized_key 

pub fn serialized_key<V: Source + Sink>(
    ast: &Ast,
    request: &ProbeRequest,
    bytes: &[u8],
) -> Result<V, ProbeError>

Decode the writer’s own serializedKey (DDSI-RTPS 2.5 §9.4.2.11) — the key-only payload behind a dispose/unregister DATA’s K flag — in the representation and byte order request names.

Unlike key_holder, which always reads the canonical big-endian PLAIN_CDR2 Key Holder XTypes 1.3 §7.6.8 fixes for computing the KeyHash, this reads exactly what a writer put on the wire: only the @key members — recursing into a nested keyed aggregate’s own @key members the same way — in declaration order, framed by the type’s OWN extensibility (a DHEADER for @appendable/@mutable under XCDR2, a per-member EMHEADER for @mutable, nothing for @final or under XCDR1), in request’s own encoding and endianness. Measured against Eclipse Cyclone 11.0.1 (ddsi_serdata_from_sample(sertype, SDK_KEY, …) + ddsi_serdata_to_ser): the key member kept its declared position among the type’s other members (a @key member need not be the first, or even present, in what a truncated-sample reading of the same bytes would decode), and a nested @appendable key member came back with its own DHEADER inside the outer one.

request.key_holder/key_holder_order/key_holder_nesting select this reading: AsDeclared combined with Declaration order (and Recursive nesting, already the default) is the wire form; nothing here touches the canonical hash-computation form (ForcedFinal combined with AscendingMemberId) key_holder and the rest of this module use.

Non-key members come back at their default value — the wire payload never carried them — through the same Purpose::Key “holder” path read_aggregate already takes for key_holder’s canonical form; a caller after the KeyHash reads it off the decoded key values through the existing canonical encoder, never from this value directly.

Unlike decode, nothing here tolerates leftover bytes as a forward-evolved writer’s appended members: a serializedKey carries only the key members and nothing else can legitimately follow one, so any byte trailing finds past the declared padding is refused.

Errors

ProbeError naming the path or the offset: a context plan() cannot describe, a payload the plan’s shape does not fit, a value the planned type refuses, or bytes left over the padding count does not account for.