feat(grpc): Support span streaming #6204
2 issues
code-review: Found 2 issues (1 high, 1 medium)
High
continue_trace return value discarded breaks distributed tracing in span streaming path - `sentry_sdk/integrations/grpc/aio/server.py:60-71`
In the new span_streaming branch, sentry_sdk.traces.continue_trace(dict(context.invocation_metadata())) is called but its return value is discarded, and the subsequent start_span is not wrapped in the returned context. As a result, incoming trace headers from gRPC invocation metadata are not propagated, so server spans will not be linked to the upstream trace—breaking distributed tracing for streaming-enabled clients. Compare to the legacy branch below which correctly threads the continued transaction into start_transaction.
Medium
Test asserts on spans[1] without verifying length, risking IndexError - `tests/integrations/grpc/test_grpc_aio.py:144-149`
In test_grpc_server_starts_transaction, the streaming branch retrieves spans and immediately uses spans[0] and spans[1] without asserting the list has at least 2 elements. If the gRPC server emits only one span (e.g., due to flush timing or implementation changes), the test will fail with an IndexError instead of a clear assertion failure, masking the actual issue and making debugging harder.
Also found at:
tests/integrations/grpc/test_grpc.py:89-91
Duration: 1m 40s · Tokens: 293.8k in / 2.2k out · Cost: $1.74 (+merge: $0.00)
Annotations
Check failure on line 71 in sentry_sdk/integrations/grpc/aio/server.py
sentry-warden / warden: code-review
continue_trace return value discarded breaks distributed tracing in span streaming path
In the new span_streaming branch, `sentry_sdk.traces.continue_trace(dict(context.invocation_metadata()))` is called but its return value is discarded, and the subsequent `start_span` is not wrapped in the returned context. As a result, incoming trace headers from gRPC invocation metadata are not propagated, so server spans will not be linked to the upstream trace—breaking distributed tracing for streaming-enabled clients. Compare to the legacy branch below which correctly threads the continued transaction into `start_transaction`.
Check warning on line 149 in tests/integrations/grpc/test_grpc_aio.py
sentry-warden / warden: code-review
Test asserts on spans[1] without verifying length, risking IndexError
In `test_grpc_server_starts_transaction`, the streaming branch retrieves `spans` and immediately uses `spans[0]` and `spans[1]` without asserting the list has at least 2 elements. If the gRPC server emits only one span (e.g., due to flush timing or implementation changes), the test will fail with an IndexError instead of a clear assertion failure, masking the actual issue and making debugging harder.
Check warning on line 91 in tests/integrations/grpc/test_grpc.py
sentry-warden / warden: code-review
[WWF-PPW] Test asserts on spans[1] without verifying length, risking IndexError (additional location)
In `test_grpc_server_starts_transaction`, the streaming branch retrieves `spans` and immediately uses `spans[0]` and `spans[1]` without asserting the list has at least 2 elements. If the gRPC server emits only one span (e.g., due to flush timing or implementation changes), the test will fail with an IndexError instead of a clear assertion failure, masking the actual issue and making debugging harder.