fix(openai): keep responses streams alive#3806
Conversation
|
This pull request targeted The base branch has been automatically changed to |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces keep-alive and heartbeat mechanisms to prevent connection timeouts for both SSE streaming and WebSocket connections. Specifically, it adds a keep-alive ticker to the OpenAI SSE handler to periodically send keep-alive comments, and implements a background heartbeat goroutine for WebSockets that sends ping messages and manages read/write deadlines. A unit test has also been added to verify the WebSocket heartbeat functionality. There are no review comments, and I have no additional feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
![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: cfdd11a278
ℹ️ 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".
| _ = conn.SetReadDeadline(time.Now().Add(responsesWebsocketReadTimeout)) | ||
| conn.SetPongHandler(func(string) error { | ||
| return conn.SetReadDeadline(time.Now().Add(responsesWebsocketReadTimeout)) |
There was a problem hiding this comment.
With this read deadline, the only downstream reads happen in ResponsesWebsocket before each request, while forwardResponsesWebsocket waits on upstream chunks and writes events without reading from conn. For any upstream response that keeps the server in that forwarding loop for more than 60 seconds, pong frames are not processed to refresh the deadline, so the next ReadMessage after the response returns a timeout and closes the session even if the client answered every ping; this breaks follow-up response.append/next-turn messages on long responses. Either drain control frames while forwarding or avoid a read deadline that cannot be refreshed during streaming.
Useful? React with 👍 / 👎.
sususu98
force-pushed
the
dev
branch
2 times, most recently
from
80d61a3 to
ac4017e
Compare
1 participant
Summary
Tests