Circuit

The circuit

Blocking: slow inbound messages

Block the circuit. The Timeline shows a Slow inbound message, the Circuit panel the maximum inbound processing time, and Diagnostics a slow event handler. Block it three times within a minute and Diagnostics adds 3 inbound messages blocked the circuit for ≥ 100 ms each. The fix: never block in a handler - await the work instead.

Block 5× in a row shows where the circuit's own timing stops: only the first block is part of the click's inbound message, because the handler awaits after it; the other four run in continuations, which no inbound message contains - a message that arrives meanwhile, such as the browser acknowledging a render, waits for them, and that wait is what its time shows. The slow event handler's duration spans all five.

The Circuit panel and the server process

• Circuit (Server only): this circuit's connection, age, disconnects, inbound messages with their average and maximum time, the browser's reconnect state, and what the browser received - bytes and render batches, the largest one, and traffic ↗ to Network → WebSockets. Below it every circuit of the process, with its lifecycle counters only, and this circuit's events.
• Runtime → Server process, shared by every circuit: the thread pool and its queue, lock contention, the working set, processors and the GC mode, next to the managed heap and collections.

Dropping: a connection that comes back

Drop the connection closes the circuit's WebSocket from the browser, as a network hiccup, a laptop that slept or a proxy that cuts idle sockets would; the circuit itself stays on the server. Blazor shows its reconnect dialog and reconnects in a moment. The Circuit panel then counts the disconnect, Browser shows the reconnect state and how many reconnects there were, the Timeline has the circuit's Connection down and Connection restored with Blazor's own reconnect states in between (Reconnect show, retrying, hide), and Network → WebSockets shows the old socket closed and a new one carrying the circuit. Drop it twice within two minutes and Diagnostics reports circuit instability.

Killing: the circuit's last moments

Each circuit has a BevTools session of its own, and the panel renders over that circuit, so when the circuit dies the panel stops where it was. Open the companion window (⧉ in the panel header) first, then kill the circuit: the companion reads the page itself, so Network → WebSockets shows the circuit's last message, a JS.Error, and its socket closing, and the status line says the runtime is disconnected. Reload for a new circuit and a new session.