Summary
Long-lived hard HTTP-bridge sessions can repeatedly reconnect to a fresh upstream WebSocket but never receive response.created. The proxy then escalates the retry circuit cooldown while the client repeatedly reconnects and eventually reaches its reconnect limit.
Observed behavior
On 2026-08-07, a hard session_header bridge session produced repeated eventless timeouts:
http_bridge_event event=missing_response_created_timeout pending=1
http_bridge_event event=reader_failure detail=upstream_request_timeout
http_bridge_retry_circuit event=opened failures=2 cooldown_seconds=60
...
failures=7 cooldown_seconds=600
The same behavior also occurred once for an internal_unanchored_parallel request. The service remained healthy, but the client-visible task could not complete.
Safety constraint
For a continuation carrying previous_response_id, replaying the request is ambiguous: the upstream may have accepted the original request even though the acknowledgement was lost. Switching accounts also breaks account-bound continuity. Without an upstream idempotency key or request-status lookup, the proxy must currently fail closed rather than risk duplicate tool calls.
Requested upstream direction
Please provide one of:
- an idempotency key/status lookup for
response.create, or
- a documented way to reconnect an existing response operation without resubmitting it.
In the meantime, the proxy-side changes in the linked PR add durable operation ownership/recovery, bounded event persistence, stale owner-cache reconciliation, and diagnostics while preserving the fail-closed duplicate-prevention boundary.
Acceptance criteria
- A hard continuation can survive an upstream WebSocket replacement without client session restart.
- An ambiguous
response.create is not executed twice.
- Cooldown/retry state is durable across process restart.
- The client receives a structured retry signal instead of an opaque stream disconnect when recovery is impossible.
Related: #1167, #881, #1563, #1611
Summary
Long-lived hard HTTP-bridge sessions can repeatedly reconnect to a fresh upstream WebSocket but never receive
response.created. The proxy then escalates the retry circuit cooldown while the client repeatedly reconnects and eventually reaches its reconnect limit.Observed behavior
On 2026-08-07, a hard
session_headerbridge session produced repeated eventless timeouts:The same behavior also occurred once for an
internal_unanchored_parallelrequest. The service remained healthy, but the client-visible task could not complete.Safety constraint
For a continuation carrying
previous_response_id, replaying the request is ambiguous: the upstream may have accepted the original request even though the acknowledgement was lost. Switching accounts also breaks account-bound continuity. Without an upstream idempotency key or request-status lookup, the proxy must currently fail closed rather than risk duplicate tool calls.Requested upstream direction
Please provide one of:
response.create, orIn the meantime, the proxy-side changes in the linked PR add durable operation ownership/recovery, bounded event persistence, stale owner-cache reconciliation, and diagnostics while preserving the fail-closed duplicate-prevention boundary.
Acceptance criteria
response.createis not executed twice.Related: #1167, #881, #1563, #1611