fix: resolve streaming endpoint deadlock by pre-consuming request body #426
Conversation
- Fix infinite hang issue in /v1/message:stream endpoint - Pre-consume request.body() in _handle_streaming_request to prevent deadlock - EventSourceResponse context was causing request.body() consumption to block - Add comprehensive error handling for body consumption failures - Add regression tests for streaming endpoint request body handling Fixes deadlock where request.body() consumption inside EventSourceResponse context caused the event loop to hang indefinitely. Breaking changes: None Backward compatibility: Maintained
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @youngchannelforyou, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request addresses a critical deadlock issue in the /v1/message:stream endpoint, which caused the application to hang indefinitely. The fix involves pre-consuming the request body before initiating the EventSourceResponse, ensuring that the request.body() operation does not block the event loop. This change also includes robust error handling for body consumption failures and introduces new regression tests to validate the fix and ensure stability of the streaming functionality.
Highlights
- Deadlock Resolution: Implemented a fix for an infinite hang in the /v1/message:stream endpoint by pre-consuming the request body.
- Request Body Handling: Modified _handle_streaming_request to explicitly consume request.body() early, preventing conflicts with EventSourceResponse context.
- Error Handling: Added comprehensive error handling for potential failures during request body consumption.
- Regression Tests: Introduced new test cases to validate the fix for the streaming endpoint's request body handling and ensure its robustness.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request effectively resolves a deadlock in the streaming endpoint by pre-consuming the request body. The fix is well-reasoned and accompanied by solid regression tests that validate the solution and prevent future hangs. My main feedback is to improve the error handling for cases where pre-consuming the request body fails. Instead of just logging a warning, raising an exception would provide a clearer, more immediate failure signal, preventing subsequent obscure errors and allowing for a proper error response to be sent to the client.
🤖 I have created a release *beep* *boop* --- ## [0.3.4](v0.3.3...v0.3.4) (2025-09-02) ### Features * Add `ServerCallContext` into task store operations ([#443](#443)) ([e3e5c4b](e3e5c4b)) * Add extensions support to `TaskUpdater.add_artifact` ([#436](#436)) ([598d8a1](598d8a1)) ### Bug Fixes * convert auth_required state in proto utils ([#444](#444)) ([ac12f05](ac12f05)) * handle concurrent task completion during cancellation ([#449](#449)) ([f4c9c18](f4c9c18)) * Remove logger error from init on `rest_adapter` and `jsonrpc_app` ([#439](#439)) ([9193208](9193208)) * resolve streaming endpoint deadlock by pre-consuming request body ([#426](#426)) ([4186731](4186731)) * Sync jsonrpc and rest implementation of authenticated agent card ([#441](#441)) ([9da9ecc](9da9ecc)) ### Performance Improvements * Improve performance and code style for `proto_utils.py` ([#452](#452)) ([1e4b574](1e4b574)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
3 participants
/v1/message:streamendpointrequest.body()in_handle_streaming_requestto prevent deadlockEventSourceResponsecontext was causingrequest.body()consumption to blockFixes deadlock where
request.body()consumption insideEventSourceResponsecontext caused the event loop to hang indefinitely.Breaking changes: None
Backward compatibility: Maintained
Fixes #1001 🦕
Release-As: 0.3.4