Expand description
Incremental Server-Sent Events parsing, and the typed events the daemon emits.
§Incremental because the transport picks the read boundaries
A single data: line routinely arrives split across two chunks, and a parser that
assumes a read boundary is a frame boundary loses output at exactly the moment the
stream gets busy. So bytes are buffered until a blank line proves a frame is
complete, and a trailing partial frame stays in the buffer.
Only the subset the daemon emits is implemented: named events with one data: line
of JSON, plus the : keepalive comments axum sends every fifteen seconds. id: and
retry: are ignored rather than half-supported — the daemon does not send them, and
the byte offset is the resume cursor rather than Last-Event-ID.
§Why not an eventsource crate
The daemon’s SSE is two field names and three event names, and the interesting part
of a client’s stream handling is the cursor rather than the framing. An eventsource
crate would bring a reconnect policy keyed on Last-Event-ID, which is the wrong
cursor: it resumes at an event, and this protocol resumes at a byte. The framing
parser below is first-party for that reason, not from any aversion to dependencies.
Structs§
- Frame
- One complete SSE frame: its event name and its raw
data:text. - SseParser
- Feed bytes, get whole frames out. Holds a partial frame across feeds.
Enums§
- Exec
Event - One decoded stream event.
Constants§
- MAX_
PENDING_ BYTES - The ceiling on bytes held for a frame that has not terminated (BIND-22).
Functions§
- decode
- Maps one frame onto a typed event.