Open ChenX1993 opened 3 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 88.83%. Comparing base (
49a0061
) to head (6e0853b
). Report is 3 commits behind head on dev.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Problem
Span leak is a issue in observability tracing where a span is started, but is not finished. The span will not be sent to tracing backend if it is not finished, hence causing incomplete traces.
Internally at Uber, we fond incomplete traces from time to time due to span leak caused in tchannel-go library. In the happy path, the span is properly finished, but the span leak issue in tchannel-go happens in error path when a function early returns with error.
E.g. https://github.com/uber/tchannel-go/blob/af146f5a54ac5787563a6857ed9b6ff26394f0ca/thrift/client.go#L139-L152 In above code snippet, A span is created within
c.startCall
, and is finished withinreadResponse
whenreader.Close()
is executed. If there is an error occurred inwriteArgs
, then the span leak happens.This PR is to fix the span leak issue.
Change Summary
finishSpanWithOptions
method that allowsspan.Finish()
to be invoked many times inInboundCallResponse
. 2.2 . UsefinishSpanWithOptions
indispatchInbound
to always try to finish a span after the handler is called.finishSpanWithOptions
inOutboundCallResponse
similar to inbound case 3.2. UsefinishSpanWithOptions
json, thrift and raw clients.Next
At Uber, YARPC (yarpc-go) is often used as a umbrella RPC framework with gRPC, TChannel and HTTP as transports. When YARPC is used with TChannel, the span leak issue does also exist.
With this PR, the span leak in inbound is expected to be fixed for YARPC as well, but for outbound, we need to add
defer call.Response().Done
here in yarpc-go after this PR is merged.