fix(grpc): handle None server interceptors - #19864
Open
ramannanda9 wants to merge 3 commits into
Open
Conversation
ramannanda9
force-pushed
the
fix/grpc-none-interceptors
branch
from
August 25, 2026 21:10
0c8a64d to
deaddcd
Compare
emmettbutler
approved these changes
Aug 26, 2026
emmettbutler
left a comment
emmettbutler
left a comment
Collaborator
There was a problem hiding this comment.
Thanks for the contribution!
Ray 2.58 passes interceptors=None when it constructs an internal async gRPC server without authentication. The tracing wrappers previously tried to convert that value to a tuple and failed before server startup. Normalize missing, empty, and None interceptor values to the Datadog interceptor tuple while preserving Datadog-first ordering for non-empty user interceptors.
ramannanda9
force-pushed
the
fix/grpc-none-interceptors
branch
from
August 26, 2026 17:52
deaddcd to
7720f4d
Compare
dubloom
approved these changes
Aug 27, 2026
dubloom
left a comment
dubloom
left a comment
Contributor
There was a problem hiding this comment.
Straightforward and great contribution, thank you for the fix !
This comment has been minimized.
This comment has been minimized.
gnufede
approved these changes
Aug 27, 2026
Comment on lines
+231
to
232
| if kwargs.get("interceptors"): | ||
| kwargs["interceptors"] = (interceptor,) + tuple(kwargs["interceptors"]) |
Member
There was a problem hiding this comment.
You can use walrus operator here to avoid accessing kwargs twice, same below in 245+246
Suggested change
| if kwargs.get("interceptors"): | |
| kwargs["interceptors"] = (interceptor,) + tuple(kwargs["interceptors"]) | |
| if interceptors := kwargs.get("interceptors"): | |
| kwargs["interceptors"] = (interceptor,) + tuple(interceptors) |
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
5 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.
Description
Handle explicit
interceptors=Nonewhen ddtrace wraps synchronous and asynchronous gRPC server constructors.Both gRPC APIs define
interceptorsas optional. The wrappers previously checked only whether the keyword was present, then attemptedtuple(None), raisingTypeErrorbefore the server could start. Ray 2.58 exposed this by passinginterceptors=Nonewhen creating an internal async gRPC server without authentication.Treat
Nonelike an omitted or empty interceptor sequence while preserving Datadog-first ordering for non-empty user interceptors.Testing
scripts/run-tests --venv 9a13b9a --venv 53b1ba3 -- -- -k test_server_accepts_explicit_none_interceptorsscripts/run-tests --venv 9a13b9a --venv 53b1ba3 -- -sscripts/lint checksRisks
Low. The change only affects server construction when
interceptorsis missing, empty, orNone; non-empty interceptor sequences retain their existing ordering.Additional Notes
This was observed with Ray 2.58 and ddtrace 3.19.8. ddtrace 3.x is EOL, but if maintainers consider the startup crash critical, a 3.19 backport would help users unable to move immediately to 4.x.
We are fine with moving to 4.x, but the bug is present there as well.