Inspect GraphQL evidence in network.har and treat streaming details as a separate handoff requirement. A successful transport response can still carry an application error.

Inspect GraphQL

Open network.har in a HAR viewer or editor. Find the operation by URL, postData, operation name, variables, time, or subject identifier, then inspect its request and response content.

An HTTP 200 response can contain GraphQL errors. Read the error details and returned data together; partial data can matter to the visible result. Add the operation and relevant fields to the issue without assuming the HTTP status alone determines success.

Evaluate EventStream evidence

The standard bundle does not guarantee a portable copy of Recorder’s EventStream message view. Inspect any HTTP headers and content present in network.har, plus stream observations the tester wrote into session.md or notes.md. A long-lived connection may not have a conventional completed response body.

Capture duration and payload limits still apply. Missing messages can reflect retention or capture availability rather than a server that sent nothing.

Evaluate WebSocket evidence

WebSocket frames are not included in the standard bundle. A HAR entry can establish connection context without preserving the message sequence. Use separately supplied notes or a dedicated protocol capture when frame content is decisive. Distinguish connection establishment from message-level behavior.

Do not assume a WebSocket frame can be reproduced as an ordinary HTTP request.

Choose the handoff format

network.har carries HTTP request/response evidence. WebSocket frames are not included in the standard bundle, and EventStream Viewer details do not have a guaranteed full-fidelity equivalent in another HAR viewer.

Ask the tester to record important stream observations and timestamps in Description or a source-linked note before producing a new bundle. Review message content for sensitive values before copying it.

Use capture support for retention and size boundaries.