Repository navigation
The documented interceptor order puts Sentry outside the exception handler; sentry.py and the dishka provider put it inside #49
Description
Version: grpc-server-kit 0.2.0.
The module docstring of grpc_server_kit/aio/interceptors/__init__.py gives the "canonical execution order (outermost first)" as:
5. AsyncSentryInterceptor (error tracking)
6. AsyncExceptionHandlerInterceptor (exception → gRPC status mapping)
That puts Sentry outside the exception handler. The rest of the package says the opposite:
AsyncSentryInterceptor's docstring: "Place this interceptor INSIDE the exception handler in the chain (later in the interceptor list) so it observes raw handler exceptions before they are mapped intogrpc.aio.AbortError."GrpcServerInterceptorsProvider(aio/dishka/interceptors.py) appends the exception handler first and Sentry after it, with a comment saying why.
Following the module docstring loses error reports: with Sentry outside, the reporter only sees the AbortError the handler produced, never the original exception. We reproduced this against a real server: an internal ValueError reaches the client as INTERNAL, and the reporter captures nothing.
Fix
Swap items 5 and 6 in the module docstring, ideally with the reason ("inside the handler, so it sees the original exception").
Activity
AlexeyShalaev commentedon Oct 16, 2026
Confirmed. I went through every place that states the order: the
AsyncSentryInterceptordocstring,GrpcServerInterceptorsProvider, the README, the quickstart, interceptors and observability guides,docs/agents.mdandexamples/observability_chain.pyall put Sentry inside the exception handler. The module docstring ofgrpc_server_kit/aio/interceptors/__init__.pyis the only one that disagrees.Plan:
AbortErrorthe handler turns it into).GrpcServerInterceptorsProvideractually builds. It fails on master. The docstring and the provider drifted apart once already; this keeps them together.Not doing anything beyond that: the code and the rest of the docs are right, so this stays a
docs:change.AlexeyShalaev commentedon Oct 16, 2026
Fixed in #51: items 5 and 6 are swapped, with a line on why Sentry sits inside the handler. A unit test now compares the numbered list in the module docstring with the chain
GrpcServerInterceptorsProviderbuilds, so the two can't drift apart again. The rest of the docs already had the right order.docs: put Sentry inside the exception handler in the documented inter…