pub struct Fetch {
pub request_id: VarInt,
pub track_namespace: TrackNamespace,
pub track_name: Vec<u8>,
pub parameters: Vec<KeyValuePair>,
}Expand description
FETCH (0x16), rebuilt in draft-20 (Section 10.13, Figure 16).
FETCH Message {
Type (vi64) = 0x16,
Length (16),
Request ID (vi64),
Track Namespace (..),
Track Name Length (vi64),
Track Name (..),
Number of Parameters (vi64),
Parameters (..) ...
}§What went, and why draft-19’s shape cannot be ported
Draft-19’s FETCH opened with a Fetch Type that chose between a Standalone
Fetch — a namespace, a name and an inline Start Location / End Location
pair — and a Joining Fetch of two varints. Draft-20 deleted the field, both
structures, the Fetch Type registry and the whole joining mechanism, and
promoted the namespace and the name to fields of FETCH itself, in the
positions they held inside the old Standalone Fetch. What is left is
byte-identical to Subscribe apart from the type code.
The range now travels in the LOCATION_FILTER parameter (Section 5.1.2). A
FETCH with none covers {0,0} through Largest Object, inclusive.
§INVALID_RANGE and a relative start
Section 10.13 keeps draft-19’s rule: “If no Objects have been published for
the track or Start Location is greater than the Largest Object” then “the
publisher MUST return REQUEST_ERROR with error code INVALID_RANGE”. A
relative start —
the one-field LOCATION_FILTER with StartGroup = 0, which resolves to the
Next Group — is by construction greater than Largest Object, so read
literally the rule rejects every relative-start FETCH. That is plainly not
the intent and the text carves out nothing, so this codec does not apply
the Start-greater-than-Largest test to a relative start, and neither
should a caller. Nothing here can enforce either reading: the test needs
Largest Object, which is track state rather than anything in this frame, so
the decision belongs to the endpoint and is recorded here because this is
where the filter arrives.
The codepoint did not change. A draft-19 decoder fed one of these reads
the Number of Track Namespace Fields count as a Fetch Type and
mis-parses without complaint; there is no in-band version signal to catch
it. That is why draft-20 has a FETCH decoder of its own rather than sharing
draft-19’s.
Fields§
§request_id: VarInt§track_namespace: TrackNamespace§track_name: Vec<u8>§parameters: Vec<KeyValuePair>