-
Notifications
You must be signed in to change notification settings - Fork 463
fix(server/sse): potential goroutine leak in Heartbeat sender #236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WalkthroughThis change updates the keep-alive ping mechanism in the Changes
Possibly related PRs
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🔇 Additional comments (1)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch!
Currently, there's one potential goroutine leak scenario caused by blocking sends to the
session.eventQueue
channel in the SSEServer heartbeat logic. The problematic case occurs under the following conditions:session.eventQueue
channel is full(buffered channel with a fixed size of 100)r.Context.Done()
orsession.done
being closed), and no one is left consuming fromsession.eventQueue
4.1 A goroutine leak
4.2 The
session
and its associated channels(eventQueue
, etc.) staying alive longer than needed4.3 Potential memory pressure and scalability issues under high-concurrency or long-running conditions
This issue can be reproduced in edge cases where the client disconnects or becomes slow, and the server continues trying to send heartbeat messages at a fixed interval.
[Que1 ]Why not add
case <- r.Context.Done()
in the new addedselect
statement ?Note that the main SSE handler will
close(session.done)
whenr.Context
is cancelled, so I think there's no need to monitor this case in the addedselect
statement[Que2] Is it possible that the main SSE handler will exit when
session.eventQueue
is full?Due to Go's select semantics, when multiple cases are ready (e.g., a message is available in eventQueue and r.Context().Done() is also ready), the runtime picks one at random. This can cause the main goroutine to exit before draining eventQueue, leaving producer goroutines blocked indefinitely.
Summary by CodeRabbit