Conversation
Keeps WebSocket support explicit so custom and proxy providers default to the safer HTTP streaming path. Updates built-in providers, configuration examples, test fixtures, and provider deserialization coverage.
Falls back to HTTP streaming when a provider does not advertise WebSocket capability. Uses consistent correlation headers so compatible gateways can preserve session and prompt-cache routing.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: afb73413f1
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if !self.provider.supports_websockets { | ||
| warn!( | ||
| "responses_websocket transport is disabled for this provider; using responses HTTP stream" | ||
| ); | ||
| return self.stream_responses(prompt, log_tag).await; |
There was a problem hiding this comment.
Existing custom providers with wire_api = "responses_websocket" but no new supports_websockets setting deserialize that capability as false, so this branch silently switches them to HTTP. This breaks WebSocket-only providers that do not expose POST /responses; it also invalidates the configuration emitted by scripts/mock_responses_websocket_server.py:161-165. Treat the explicit WebSocket wire API as capability, or provide a compatibility-preserving migration.
Useful? React with 👍 / 👎.
| if self.websockets_disabled.load(Ordering::Relaxed) | ||
| || !self.provider.supports_websockets | ||
| { | ||
| return None; |
There was a problem hiding this comment.
The new tests only verify provider deserialization and defaults; none exercises ModelClient::stream. Add request-level integration cases proving that WebSocket-preferring WireApi::Responses and explicit WireApi::ResponsesWebsocket providers go directly to HTTP when unsupported, while supports_websockets = true still selects WebSocket. Without this, the central dispatch behavior—and the compatibility regression for existing explicit WebSocket configurations—can go unnoticed.
AGENTS.md reference: AGENTS.md:L23-L23
Useful? React with 👍 / 👎.
| .header("x-client-request-id", session_id) | ||
| .header("session-id", session_id) | ||
| .header("thread-id", session_id) |
There was a problem hiding this comment.
No request-level test verifies this header migration across HTTP streaming, WebSocket handshakes, or compaction. Add integration assertions that x-client-request-id, session-id, and thread-id contain the expected session override and that the legacy underscore headers are absent; otherwise a typo or a missed call site can silently break gateway routing and prompt-cache correlation.
Useful? React with 👍 / 👎.
2 participants
Summary
supports_websocketscapability to model providers.Motivation
Model metadata can prefer responses over WebSocket, but an OpenAI‑compatible provider may only support the HTTP responses endpoint. Previously, the code-rs treated model preference as sufficient and could attempt an unsupported transport.
This change keeps existing custom providers on the safer HTTP path while preserving WebSocket behavior for the built‑in OpenAI provider.
No gateway‑specific behavior or configuration is hardcoded.