In a Server-Sent Events feed, what does adding an `event: fault` line change about the block it appears in?

## What the field does, and what it does not A dispatched event carries exactly two things: a **type** and a **payload**. The `event` field sets the first of those. Written as `event: fault`, it says the event this block eventually dispatches is of type `fault`; the value is arbitrary text compared literally, so `fault`, `Fault` and `FAULT` are three different types. It is worth being blunt about what naming a type does *not* change: - It does not change how the block ends. A blank line still dispatches, and only a blank line. - It does not change how `data` lines are assembled into the payload. - It does not appear in the payload. The type travels beside the payload, not inside it. - It does not filter anything on the wire. Every block in the response reaches the client regardless of its type; selecting among them is the receiving application's job. - It does not declare a schema. Nothing validates that two `fault` events have the same shape. ## The default type A block with no `event` line still has a type. The default is the literal string `message`, and it is the type every unnamed block dispatches: | block on the wire | type dispatched | payload | |---|---|---| | `data: {...}` then blank line | `message` | the assembled text | | `event: fault` + `data: {...}` then blank line | `fault` | the assembled text | | `event: fault` then blank line, no data line | nothing dispatched | - | The third row is the one that surprises people: the type buffer alone is not enough to produce an event. If the payload buffer is empty when the blank line arrives, the client dispatches nothing and clears both buffers. The practical consequence of the default is the classic silent failure. An application that only ever handles the default type receives nothing at all from blocks that named one, because those events were dispatched under a different name and no one was listening for it. The events arrived; they were just delivered under a label nothing was watching. ## Per block, never sticky After every dispatch the client clears the type buffer along with the payload buffer. So: 1. A block that names `fault` dispatches type `fault`. 2. The next block, naming nothing, dispatches type `message` - **not** `fault`. 3. A third block naming `position` dispatches type `position`. An emitter that names a type once and then assumes the rest of the stream inherits it is publishing most of its events as the default type without noticing. There is no way to set a type for the response as a whole; if every event is a fault, every block writes `event: fault`. ## Why multiplex types down one response A building-operations console watching a bank of cars wants several kinds of update: a car moved, a door state changed, a fault opened, a fault cleared. The alternatives are one held-open response per kind, or one response carrying typed blocks. The second wins for a reason that has nothing to do with elegance: each held-open response occupies a connection, and connections to one origin are a limited and contended resource for a client. One response carrying four types costs one; four responses cost four. The cost of multiplexing is on the receiving side - it must demultiplex by type - and that is cheap, because the type is already parsed out for it. ## Choosing type names A few properties are worth designing for deliberately: - **Stable.** The name is part of your contract with every receiver; renaming `fault` to `alarm` silently stops delivering to anyone still routing on the old name. - **Coarse enough to route on, fine enough to matter.** One type per kind of update, not one per car. - **Distinct from the default.** Naming a type `message` is legal and means exactly what an unnamed block means, which makes the stream harder to read and gains nothing. - **Free of structure.** The value is opaque text; encoding fields into it (`fault.car-a.overspeed`) puts routing logic into a label instead of the payload. ## Where this goes wrong - Assuming an unnamed block has no type. It has one: `message`. - Assuming a named type persists to later blocks. It never does. - Expecting the name to be matched loosely. It is compared literally, like the field names themselves. - Writing the type into the payload as well and then routing on the payload copy, which quietly makes the wire-level type decorative.