Scenario · Network
Orders
Network problems to diagnose: a slow endpoint, a flaky endpoint that fails two thirds of the time, a burst of
identical requests, a 404, a load you can cancel and a table whose rows each load their own details. Every
request goes through IHttpClientFactory, so BevTools sees it with no change to the code that sends
it.
The orders client
Each button calls the demo's own API (/api/orders, /api/flaky,
/api/products, and an address that does not exist). On the Server renderer these requests are made
by the server, so the browser's own network tab never sees them.
Network: durations, statuses, triggers
The Network panel lists every request with its method, address, status, duration and size,
and the UI event that triggered it - onclick → Orders.Flaky, or onclick → Orders.Load (lambda)
for a button whose handler is a lambda that calls Load. Select a request for its headers (sensitive
ones redacted; bodies are never captured) and the code that sent it. The column headers sort the list, and
the filter box narrows it.
- Press Load orders (very slow), then Cancel loading: the request is shown as cancelled, not as a failure, and nothing reaches the Errors panel.
- Tick each row loads its own details and load the orders. The click rendered the rows, so the Trigger column links all 25 requests to it; select one and Sent from names the code that actually sent it - OrderRow.OnInitializedAsync via ProductApi.GetOrderDetailsAsync - which no trigger can tell you. A request no click caused shows its sender in the Trigger column itself, like the dashboard's from RecentOrders.Reload.
Network → Endpoints: requests per endpoint
Endpoints groups the same requests by method and path, with the ids in the path as {id}:
the 25 calls to GET /api/orders/{id} are one row, with their failures, cancellations, p50, p95 and
maximum durations, the bytes received and the component that sent them most. Select an endpoint for its
requests.
Errors and Diagnostics: what went wrong
- Errors: the failed flaky calls and the 404, each with the UI event that preceded it.
- Diagnostics: slow HTTP request and slow event handler (the loads, the 4 s one above all), repeated HTTP failures (call the flaky endpoint a few times), duplicate HTTP requests (the burst of 8 identical ones) and one request per item (load the orders with each row loads its own details ticked).