Aiohttp support

[mike-hart]

I don't see a clear way to integrate with aiohttp (server) just yet. I can still use raven at present, but I imagine sentry-python/sentry-sdk is the proposed way forward longer term?

[untitaker]

Hi, we currently don't have any integration with aiohttp-server on the new sdk. If anybody is interested in this feature please just vote with reactions on the OP and we'll prioritize accordingly.

[mitsuhiko]

@mike-hart what do you have in mind there? Afaik the old SDK also did not have an aiohttp integration (just an aiohttp transport which we do not believe we will provide going forward).

[mike-hart]

@mitsuhiko - well, right now I'm just looking for a way to replace the error-reporting middleware I have that currently uses raven. Making sure I don't end up "stuck" using an unsupported/non-current framework. Maybe a middleware isn't the best approach, if not then some documentation or a basic recipe would be a great start.

Right now I don't know enough about sentry-sdk to know whether it'll stall an async process while contacting sentry itself, how to replace its transport if it does, whether it's threaded, whether there will be unexpected or undesired outcomes from using its defaults. All I really want is a mechanism to report uncaught exceptions (basically something that would result in a 5xx status code) to Sentry for my service.

[mitsuhiko]

@mike-hart calling any of the capture methods on the hub/client/transport are non blocking operations. They enqueue into a background queue.

[mike-hart]

@mitsuhiko - I note in https://docs.sentry.io/platforms/python/ that there's mention of httplib_request hints, is this the mechanism I should be using to add additional information to the reported exception for a service?

Raven had a semi-standard structure (the http context) you'd build to feed to the capture so that you knew URL, query params etc. Is this is the same thing, and are there any documented examples of how to build something similar for sentry-sdk? Or am I going down completely the wrong path?

[mitsuhiko]

@mike-hart i'm not entirely sure what you mean but i would propose to look at the sanic, flask and django integrations to see how this works. Integrations are pretty straightforward and can emit any kind of data. The structure from raven is very much still there, we just simplified it.

[mitsuhiko]

Eg: this is how sanic works: https://github.com/getsentry/sentry-python/blob/master/sentry_sdk/integrations/sanic.py

[mike-hart]

Thanks, I'll take a further look at the integrations and see if I can come up with something. The mechanism seems a little... invasive (at least when looking at sanic, django, and flask integrations, where they appear to monkey-patch). Is there a reason (say, in sanic's case) not to tie in to the inbuilt error-handler mechanism for example?

Anyway, thanks for the pointers. I'll have a further play around and see if I can get something together, sorry for taking up so much of your time.

[mitsuhiko]

We intentionally patch the core handlers now as there were too many issues with working with the individual error handlers that are already in place. Both in reliability and usability. More importantly we already in the past had to do invasive patching for breadcrumbs so the behavior was wildly inconsistent.

Generally the builtin error handlers are typically compromising so that they can still render error pages which swallows quite a few errors we are still interested in.

[untitaker]

So this seems to have a lot of support. Is this something that used to work just fine with raven for you? Is there a third-party package that enabled this for you?

[decaz]

@untitaker if your question is what do people use within aiohttp, I can answer for myself - raven-aiohttp and hope sentry-python will support aiohttp as it is critical feature and it's absence prevents me from using sentry-python.

[untitaker]

@decaz how does its absence prevent you from using the new SDK? Surely spawning threads like the new SDK does would still work even if it's not the optimal way to do things? I haven't tried it but it should work out of the box.

Note that as far as I can tell this is only about the transport used internally. Perhaps I don't have the full context as to why people use raven-aiohttp in the first place

[decaz]

I think people use raven-aiohttp because new SDK does not contain integration with aiohttp. And yes, this is also about the transport.