Frequent "OSError" triggered by `exception_hook` using Honeybadger for Python 0.12.0

[agdiaz]

Hello Honeybadger devs, I hope this message finds you doing well!

I've implemented the error tracking service on a Django website deployed on "Ubuntu 18.04.3 LTS". This application runs by using a uwsgi engine and behind an NGINX server.

Several times a day I received notifications related to an error coming from inside the HoneyBadger library but with an empty stack trace:

There are no further details that could help me to identify the issue inside my project's code:

Would you mind helping me to identify the root cause of this issue?

Thank you in advance for your feedback and time.

Best from Brussels! Adrián,

[joshuap]

@Kelvin4664 can you look at this one? Could it be a case where the stack trace is being generated internally when calling honeybadger.notify like this example from the README?

honeybadger.notify(error_class='ValueError', error_message='Something bad happened!', fingerprint='custom_fingerprint')

[agdiaz]

Hello there,

Thanks for checking it out! Just to add a bit more context, I'm attaching the frequency chart in order to illustrate that it's happening randomly:

I've reviewed the source code of my project, and the two places where I invoke honeybadger.notify add context using a dictionary, so these places don't seem to be related to the OSError because we should see the context at least.

Have a nice day 👋

[Kelvin4664]

Hi @agdiaz Thank you for the detailed report. There is little or no detail because the error occurred outside your application. More specifically, at the uwsgi layer which is outside honeybadger's frame. Such errors usually occur when uwsgi encounters a large request body, or having more requests than there's available workers. You can turn these notifications off from your uwsgi config by turning on the following: ignore-sigpipe ignore-write-errors disable-write-exception

@joshuap can we consider a dedicated wsgi/uwsgi intergration to help with cases like this?

[joshuap]

@joshuap can we consider a dedicated wsgi/uwsgi intergration to help with cases like this?

Yep, could you write up an issue for that feature and give it the "enhancement" label? Thanks!

[agdiaz]

@Kelvin4664 @joshuap: thank you for your help finding the root cause of these OSErrors and for proposing a workaround!

[Kelvin4664]

Will be addressed with #125