-
Notifications
You must be signed in to change notification settings - Fork 38
Description
Flask has a signal got_request_exception intended to signify that an unhandled exception occurred in a handler. This signal is triggered by the default error handler, ref: https://github.com/pallets/flask/blob/0d8c8ba71bc6362e6ea9af08146dc97e1a0a8abc/src/flask/app.py#L1675. This means that to Flask, adding error handlers is equivalent to catching an exception; their documentation attempts to explains this, but it can be easy to miss the implication that the exception signal is not sent if a registered error handler matches the exception.
Existing instrumentation/observability tooling uses this signal to detect when an unexpected error has occurred in a service.
Rebar currently registers a generic Exception error handler, ref:
flask-rebar/flask_rebar/rebar.py
Lines 818 to 827 in 63922a1
| @app.errorhandler(Exception) | |
| def handle_generic_error(error): | |
| run_unhandled_exception_handlers(error) | |
| if current_app.debug: | |
| raise error | |
| else: | |
| return self._create_json_error_response( | |
| message=messages.internal_server_error, http_status_code=500 | |
| ) |
This causes tools/plugins that rely on the got_request_exception signal to fail to work with a Rebar service.
Rebar should either
- Switch the generic error handler to register for
InternalServerError; meaning that the rebar handler would only run after the default flask handler had run and sent the got_request_exception signal. - Send the got_request_exception signal as part of it's generic exception handling.