[Serve] Preserve user-set gRPC status codes when exceptions are raised#60482
Merged
Conversation
Signed-off-by: abrar <abrar@anyscale.com>
![gemini-code-assist[bot]](https://cdn.statically.io/img/avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request introduces a valuable feature to preserve user-set gRPC status codes when exceptions are raised in Ray Serve deployments. The implementation is well-structured, introducing a gRPCStatusError to carry the context, updating replica methods to wrap exceptions, and modifying the proxy to respect the user's intended status code. The addition of message truncation is a thoughtful improvement to prevent issues with large error messages. The documentation and tests are comprehensive and clearly cover the new functionality.
I've found one potential issue related to handling asyncio.CancelledError on older Python versions, which could lead to inconsistent behavior. My specific comments provide suggestions to address this. Overall, this is a great enhancement to Ray Serve's gRPC capabilities.
ray-gardener
Bot
added
serve
Signed-off-by: abrar <abrar@anyscale.com>
Signed-off-by: abrar <abrar@anyscale.com>
harshit-anyscale
approved these changes
Jan 27, 2026
harshit-anyscale
left a comment
harshit-anyscale
left a comment
Contributor
There was a problem hiding this comment.
one minor comment, else LGTM
ans9868
pushed a commit
to ans9868/ray
that referenced
this pull request
Feb 18, 2026
ray-project#60482) Fixes ray-project#58851 ### Changes 1. **New `gRPCStatusError` exception class** - Wraps exceptions with user-set gRPC status codes so they flow through Ray's error handling path. 2. **Exception wrapping in replica methods** - `handle_request`, `handle_request_streaming`, and `handle_request_with_rejection` now wrap exceptions with `gRPCStatusError` when the user has set a status code on the gRPC context. 3. **Status code preservation in proxy** - `get_grpc_response_status()` now detects `gRPCStatusError` and returns the user's intended status code instead of `INTERNAL`. 4. **Message truncation** - Added `_truncate_message()` to limit error details to 4KB, avoiding HTTP/2 trailer size limits. 5. **Documentation updates** - Updated the gRPC guide to document the new behavior. --------- Signed-off-by: abrar <abrar@anyscale.com> Signed-off-by: Adel Nour <ans9868@nyu.edu>
This was referenced Apr 7, 2026
abrarsheikh
pushed a commit
that referenced
this pull request
Apr 17, 2026
## Why Fixes #62358. For non-gRPC Serve requests, `Replica.handle_request*` currently does: ```python raise self._maybe_wrap_grpc_exception(e, request_metadata) from e ``` When `_maybe_wrap_grpc_exception()` returns the original exception unchanged, this degenerates into `raise e from e`, creating a self-referential `__cause__` chain (`e.__cause__ is e`). That breaks error-reporting tools that walk `__cause__` recursively and can also confuse debugging and logging paths for normal HTTP and handle-based requests. ## Root cause This regression came from `#60482` (`221a19395a`), which unified exception handling across the `handle_request*` paths so gRPC requests could preserve user-set status codes. That behavior is correct when a new gRPC wrapper exception is created. It is wrong for non-gRPC requests, because `_maybe_wrap_grpc_exception()` just returns `e`, so the code effectively executes `raise e from e`. ## Fix Introduce a small `_raise_user_exception()` helper in `replica.py`: - if `_maybe_wrap_grpc_exception()` returns the original exception, raise it directly - if it returns a wrapped gRPC exception, raise the wrapped exception `from e` This preserves the intended gRPC chaining behavior while eliminating the circular `__cause__` chain on non-gRPC paths. ## Testing ```bash source /home/simple/github/ray/.venv/bin/activate PYTHONPATH=/home/simple/github/ray/.worktrees/fix-issue-62358-replica-exception-chaining/python \ python -m pytest python/ray/serve/tests/unit/test_replica_exception_chaining.py -v ``` --------- Signed-off-by: Ziy1-Tan <ajb459684460@gmail.com>
HLDKNotFound
pushed a commit
to chichic21039/ray
that referenced
this pull request
Apr 22, 2026
…62412) ## Why Fixes ray-project#62358. For non-gRPC Serve requests, `Replica.handle_request*` currently does: ```python raise self._maybe_wrap_grpc_exception(e, request_metadata) from e ``` When `_maybe_wrap_grpc_exception()` returns the original exception unchanged, this degenerates into `raise e from e`, creating a self-referential `__cause__` chain (`e.__cause__ is e`). That breaks error-reporting tools that walk `__cause__` recursively and can also confuse debugging and logging paths for normal HTTP and handle-based requests. ## Root cause This regression came from `ray-project#60482` (`221a19395a`), which unified exception handling across the `handle_request*` paths so gRPC requests could preserve user-set status codes. That behavior is correct when a new gRPC wrapper exception is created. It is wrong for non-gRPC requests, because `_maybe_wrap_grpc_exception()` just returns `e`, so the code effectively executes `raise e from e`. ## Fix Introduce a small `_raise_user_exception()` helper in `replica.py`: - if `_maybe_wrap_grpc_exception()` returns the original exception, raise it directly - if it returns a wrapped gRPC exception, raise the wrapped exception `from e` This preserves the intended gRPC chaining behavior while eliminating the circular `__cause__` chain on non-gRPC paths. ## Testing ```bash source /home/simple/github/ray/.venv/bin/activate PYTHONPATH=/home/simple/github/ray/.worktrees/fix-issue-62358-replica-exception-chaining/python \ python -m pytest python/ray/serve/tests/unit/test_replica_exception_chaining.py -v ``` --------- Signed-off-by: Ziy1-Tan <ajb459684460@gmail.com>
Lucas61000
pushed a commit
to Lucas61000/ray
that referenced
this pull request
May 15, 2026
…62412) ## Why Fixes ray-project#62358. For non-gRPC Serve requests, `Replica.handle_request*` currently does: ```python raise self._maybe_wrap_grpc_exception(e, request_metadata) from e ``` When `_maybe_wrap_grpc_exception()` returns the original exception unchanged, this degenerates into `raise e from e`, creating a self-referential `__cause__` chain (`e.__cause__ is e`). That breaks error-reporting tools that walk `__cause__` recursively and can also confuse debugging and logging paths for normal HTTP and handle-based requests. ## Root cause This regression came from `ray-project#60482` (`221a19395a`), which unified exception handling across the `handle_request*` paths so gRPC requests could preserve user-set status codes. That behavior is correct when a new gRPC wrapper exception is created. It is wrong for non-gRPC requests, because `_maybe_wrap_grpc_exception()` just returns `e`, so the code effectively executes `raise e from e`. ## Fix Introduce a small `_raise_user_exception()` helper in `replica.py`: - if `_maybe_wrap_grpc_exception()` returns the original exception, raise it directly - if it returns a wrapped gRPC exception, raise the wrapped exception `from e` This preserves the intended gRPC chaining behavior while eliminating the circular `__cause__` chain on non-gRPC paths. ## Testing ```bash source /home/simple/github/ray/.venv/bin/activate PYTHONPATH=/home/simple/github/ray/.worktrees/fix-issue-62358-replica-exception-chaining/python \ python -m pytest python/ray/serve/tests/unit/test_replica_exception_chaining.py -v ``` --------- Signed-off-by: Ziy1-Tan <ajb459684460@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #58851
Changes
gRPCStatusErrorexception class - Wraps exceptions with user-set gRPC status codes so they flow through Ray's error handling path.handle_request,handle_request_streaming, andhandle_request_with_rejectionnow wrap exceptions withgRPCStatusErrorwhen the user has set a status code on the gRPC context.get_grpc_response_status()now detectsgRPCStatusErrorand returns the user's intended status code instead ofINTERNAL._truncate_message()to limit error details to 4KB, avoiding HTTP/2 trailer size limits.