Commit bd0fc70
authored
fix(grpc): Read method from handler_call_details for grpcio >= 1.76 compat (#5521)
## Summary
Fixes sync `ServerInterceptor` to work with grpcio >= 1.76 by reading
the method name from `handler_call_details.method` instead of
`context._rpc_event.call_details.method`.
### Problem
grpcio 1.76 introduced **registered method handlers**
(`add_registered_method_handlers`) which resolve RPC methods at the
C-core level. For these registered methods,
`context._rpc_event.call_details.method` returns an empty string,
causing Sentry tracing to silently fail (no transactions, no spans, no
trace IDs in logs).
### Solution
Capture `handler_call_details.method` directly in the closure scope
before defining the `behavior` function. This approach:
1. **Fixes grpcio >= 1.76 compatibility** -
`handler_call_details.method` is always populated by grpcio's
`_find_method_handler`
2. **Avoids race conditions** - No shared instance state; each call
creates its own closure with captured values
3. **Maintains backward compatibility** - Custom `find_name` parameter
still works
### Why Closure Capture Instead of Instance State?
The gRPC sync server uses a `ThreadPoolExecutor` where multiple threads
share the same `ServerInterceptor` instance. Storing state as
`self._handler_call_details` would create a race condition where one
thread could overwrite the value before another thread's `behavior`
closure reads it.
Fixes #55201 parent 594dce5 commit bd0fc70
1 file changed
+5
-6
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
22 | 22 | | |
23 | 23 | | |
24 | 24 | | |
25 | | - | |
| 25 | + | |
26 | 26 | | |
27 | 27 | | |
28 | 28 | | |
| |||
35 | 35 | | |
36 | 36 | | |
37 | 37 | | |
| 38 | + | |
| 39 | + | |
| 40 | + | |
38 | 41 | | |
39 | 42 | | |
40 | | - | |
| 43 | + | |
41 | 44 | | |
42 | 45 | | |
43 | 46 | | |
| |||
63 | 66 | | |
64 | 67 | | |
65 | 68 | | |
66 | | - | |
67 | | - | |
68 | | - | |
69 | | - | |
0 commit comments