Expand description
Diagnostics routing: textDocument/publishDiagnostics → editor
subscribers (Phase 4.1.d.i).
§Why broadcast
A document may have multiple panes, multiple decoration
consumers (gutter glyph provider + underline overlay + the
:diagnostics buffer view), and – once §5.10’s event bus
arrives – arbitrary plugin subscribers. Each gets a clone
of every event. tokio::sync::broadcast is the right shape:
- Sender: the actor.
- Receivers: each subscriber owns one; cheap to clone the underlying queue.
- Lagging consumers drop oldest first; for diagnostics this is correct – the LATEST publish supersedes any in-flight older ones (per-version dropping is the editor’s job).
§Why a typed event vs raw PublishDiagnosticsParams
DiagnosticEvent flattens the LSP shape to what the editor
actually consumes (uri / version / diagnostics) and adds the
server_id so a multi-server setup (rust-analyzer + clippy
linter bridge) can be disambiguated by the consumer without
carrying server identity through every hop. Rest of the LSP
payload is preserved verbatim via Vec<Diagnostic>.
Structs§
- Diagnostic
Event - One diagnostics publish from the server.
- Diagnostics
Bus - The actor’s send-side diagnostics bus. One per actor; shared across read-loop, supervisor, future telemetry hooks.
Constants§
- DIAGNOSTICS_
CHANNEL_ CAPACITY - Capacity of the diagnostics broadcast channel. 256 events per server fits a fast indexer’s burst rate (rust-analyzer at startup may publish ~once per crate file). Lagged receivers drop oldest first; the editor reconciles by reading the URI’s latest event and ignoring earlier ones for that URI.