Skip to content

v0.10.46

@evalstate evalstate tagged this 13 Oct 16:47
* Responses websocket: diagnose streams that end without a completion event

When the server ends a websocket stream before `response.completed`, the error
only said `events_seen=N; last_frame=<240-char prefix>`. Against GitHub Copilot
the first frame is an untyped `{"headers": {...}}` frame whose experiment
assignment header alone exceeds 240 characters, so the preview never reached the
useful part, and a drop without a close frame reported no close details at all.
Observed in Deep-SWE runs: two frames, then the connection closed ~16 s after
the request, every attempt, with nothing to distinguish a provider close, an
intermediary reset or a policy cut.

Error message (console; not persisted by the failure event):
- names the closing condition, including `received_close=none` when the peer
  dropped the connection without a close frame, and `close_code=none`, plus
  `ws_exception=<type>`;
- `seconds_since_request` and `seconds_since_last_frame`;
- `frames=[...]`: the last five frames as event types, with Copilot header frames
  shown as header names plus `*request-id*` values that match a strict identifier
  pattern (for provider support requests); other header values are never shown.

Exception: `close_snapshot` (the persisted fields) and `last_frame`, the raw last
frame bounded to 16 KiB, for programmatic inspection only; never logged.

Persisted `Responses websocket attempt failed` event, schema bumped to v2:
`close_kind` (fixed vocabulary), `close_code` (int), `events_seen`,
`last_event_types` (allowlisted Responses event names; `headers`, `other`,
`untyped` otherwise), `seconds_since_request`, `seconds_since_last_frame`.
All null for failures that are not stream closes. No provider-controlled strings
are persisted; tests assert header values, request ids and unknown event names
stay out of the log.

No change to retry, reconnect or timeout behaviour.

* Release 0.10.46: Responses websocket close diagnostics
Assets 2
Loading