Temporary workaround to race condition

Right now there's no ordering between the set context from the SetCall callback chain in server.cc, and the read context a few lines down from the new if statement inserted here -- that is if a call is cancelled whilst the server is initializing the context we see a tsan race.

Until https://github.com/grpc/grpc/pull/36598 this was a non-issue however because we were entirely discarding the cancellation edge. Now that we've gotten that back again, this race is appearing.

I'd like us to fix this properly, but to do so probably needs some deeper work on what contexts are and how they're initialized -- and that's not for this week (but maybe this month).

PiperOrigin-RevId: 636295078
pull/36666/head
Craig Tiller 6 months ago committed by Copybara-Service
parent 990a422b1b
commit 44b7631d65
  1. 1
      src/core/ext/filters/backend_metrics/backend_metric_filter.cc

@ -129,6 +129,7 @@ BackendMetricFilter::Create(const ChannelArgs&, ChannelFilter::Args) {
} }
void BackendMetricFilter::Call::OnServerTrailingMetadata(ServerMetadata& md) { void BackendMetricFilter::Call::OnServerTrailingMetadata(ServerMetadata& md) {
if (md.get(GrpcCallWasCancelled()).value_or(false)) return;
auto* ctx = &GetContext< auto* ctx = &GetContext<
grpc_call_context_element>()[GRPC_CONTEXT_BACKEND_METRIC_PROVIDER]; grpc_call_context_element>()[GRPC_CONTEXT_BACKEND_METRIC_PROVIDER];
if (ctx == nullptr) { if (ctx == nullptr) {

Loading…
Cancel
Save