SystemExit and KeyboardInterrupt no longer caught (regression from raven-python) #379
Comments
…I middleware Neither SystemExit nor KeyboardInterrupt subclass Exception, so we must explicitly handle these two exception classes in addition to Exception in the WSGI middleware. This is notably a direct port from raven-python: - https://github.com/getsentry/raven-python/blob/master/raven/middleware.py - https://github.com/getsentry/raven-python/blob/master/tests/middleware/tests.py Fixes: getsentryGH-379
…rupt (#380) * Log SystemExit (with non-zero exit code) and KeyboardInterrupt in WSGI middleware Neither SystemExit nor KeyboardInterrupt subclass Exception, so we must explicitly handle these two exception classes in addition to Exception in the WSGI middleware. This is notably a direct port from raven-python: - https://github.com/getsentry/raven-python/blob/master/raven/middleware.py - https://github.com/getsentry/raven-python/blob/master/tests/middleware/tests.py Fixes: GH-379
|
Huh, I've the opposite issue: raven did not log this, but the new client does. Is there any way to avoid logging |
|
@WhyNotHugo can you confirm those events have the wsgi mechanism? |
|
Yes, they all do. |
|
Hmm, from what I know this means you abort gunicorn while it is handling a request and that might be the wrong way to shut it down. In any case you can explicitly ignore this error like any error class with this here: #149 (comment) |
|
Hmmm... let me double check, I believe we're killing gunicorn gracefully, but I might be wrong. |
|
Yeah, looks like docker was killing them before gunicorn's internal grace period, I'll tweak that and it should solve it for me. Thanks. |
The same reasoning as getsentry/raven-python#675 applies for sentry-python,
where gunicorn raising a SytemExit(1) is something we would like to capture
in Sentry, as it is unexpected behavior from the application.
The text was updated successfully, but these errors were encountered: