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.

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

In test_grpc_server_starts_transaction (streaming branch), the test indexes spans[0] and spans[1] and asserts that spans[1] is the GRPC_SERVER span and spans[0] is the 'test' op span. However, the order in which streamed spans are flushed/captured is not guaranteed to follow this exact sequence (parent vs child completion order can vary). If the order changes, the test will fail or pass incorrectly. The user-visible consequence is flaky tests or false confidence in span content.

Also found at:

• tests/integrations/grpc/test_grpc.py:80-82