You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @ianmetcalf
Thanks for identifying the issue and the root cause. You're right that the _handle_exception method which is the teardown_request handler is called after the segment is closed in _after_request and is failing silently while trying to add the exception.
I believe there could be two options here.
Do not close the segment in _after_request if the response.status_code is 500. Then the _handle_exception method will add the exception and close the segment.
Add a handle_user_exception handler method to the app similar to your workaround and add the exception there.
I'll test both the options and put out a fix soon.
Did some digging into why the unit tests didn't catch this behavior change. It turns out that if we enable the testing mode, the after_request is not called in case of an unhandled exception which results in segment being still available in the handle_exception method and the test passes.
When I disabled the test mode by setting app.config['TESTING'] = False, the test began to fail as expected. I think for our use case, we can keep disable the TESTING config as disabled since it is required only to propagate the exception to the test_client which we don't really need.
I think the simple fix can the option 1 mentioned above rather than setting the handle_user_exception becuase that could override the customer's application exception handling.
The
after_request
handler is closing the segment before theteardown_request
handler is called so the stack trace isn't captured.It looks like this behavior changed as of Flask v1.1.0 (specifically pallets/flask#3266)
Currently using:
Here is our current work around:
The text was updated successfully, but these errors were encountered: