ASGI Support
See original GitHub issueHi folks. I’m considering tackling an ASGI integration, that’d bring support to Starlette, Responder, Quart.
Because we’d need to monkey-path a generic application __call__
method, rather than a known class, you’d need to pass the app instance to the integration instantiation.
import sentry_sdk
from sentry_sdk.integrations.asgi import ASGIIntegration
app = Starlette()
sentry_sdk.init(
dsn="https://<key>@sentry.io/<project>",
integrations=[ASGIIntegration(app)]
)
Alternatively, you could design a generic ASGI implementation, and just have very light individual framework-specific integrations that just plugged that into starlette’s Starlette.__call__
, responder’s API.__call__
, etc…
When handled properly ASGI exceptions are still propagated out of the stack, even when a technical 500 page has been sent by the framework, so I think that along with logging there’s plenty of generic context that can be captured here.
I guess my initial questions would be:
- Should I be thinking of this in terms of a third-party library, or looking to build it in for the official sentry-python package as an integration?
- What important context am I likely to be missing out on by working at this level, rather than at a framework specific level? (It’s possible that we might get some loose patterns around where things like user state or routed endpoint should get kept in the ASGI scope dictionary, so it’s feasible we might be able to capture some of that, as well as the basic request info)
Issue Analytics
- State:
- Created 5 years ago
- Reactions:2
- Comments:19 (9 by maintainers)
Top GitHub Comments
0.10.2 adds an ASGI middleware: https://docs.sentry.io/platforms/python/asgi/
Wrt hubs see #147, you need a new hub in asyncio for now