Recover and debug
Check browser reconnection, token renewal, and stopped turns before deployment.
Use the same research application.
| Exercise | Expected observation | Where to investigate |
|---|---|---|
| Disconnect the browser network during a reply, then reconnect | The subscriber reconnects and durable messages appear once | Browser network panel and session events |
| Refresh after a completed response | The same session's conversation is rebuilt | Member-scoped session ID in browser storage |
| Leave chat open past the token's five-minute lifetime | The browser requests a new token from your application | /api/sessions/:id/token and its no-store response |
| Ask to read an unknown source ID | The tool returns found: false; it does not invent a source | read_source result in Trace |
| Click an approval already answered elsewhere | The UI reports the conflict and refreshes pending decisions | Decision endpoint's 409 response |
| Stop the local application and ask for a tool in the console | The tool cannot be served until you restart the app | Connection status and session trace |
An idle status alone does not mean success. Inspect stopReason: a completed answer,
an approval wait, and an error all need different UI behavior. The terminal quickstart
checks that the turn stopped with completed; the browser displays the actual reason.
The browser helper retries stream transport failures. That does not automatically retry your application's message writes. The starter retains a request ID after a failed send so retrying unchanged text can reuse it. A new page load does not retain that in-flight request; production apps can persist pending writes if they need that guarantee.
Read traces, delivery modes, and troubleshooting for the underlying contracts.
Next: deploy the application.