-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Let's consider improvements to how internal errors are handled in the Pbench Server #3124
Comments
Below is the reconstructed initial stack trace to the first exception raised from "Traceback 1" (the reconstruction of Traceback 2 is virtually identical). The process of reconstructing was performed by starting with the ending "Traceback" list, walking up the trace back until the first Actually, this re-construction is fuzzier than expected, but the
|
For the rest of this issue, we are going to only discuss Traceback 2 because PR #3125 corrects the extra exception handling nesting seen there. |
Here is the reconstructed traceback again, but with the last frame of the Pbench Server code expanded to the full method context. The Changes to consider:
|
Here again we reconstruct the traceback, but only to the next frame of the Pbench Server code where we handle exceptions. The Changes to consider:
|
Finally, we show the last exception handler in this call stack. The Changes to consider:
|
Summary suggestions
TBD
Initial Discussion
This is a very long description due to the nature of the stack traces discussed here. The referenced code can be found in branch https://github.com/portante/pbench/tree/PBENCH-944, the basis for PR #3081.
There are two "Tracebacks" being discussed, 1 and 2, which are in separate sections below. Both were taking from log messages emitted by the Pbench Server code
For both stack traces the core problem was a database schema that did not match the code. An attempt to delete a
Dataset
object failed because theDELETING
state was not in the stored database schema.This issue is NOT about the particular base exception, but IS about the Pbench Server code and its error handling / logging code paths.
Both stack traces are logged via the
log_exception()
method of theFlask()
"app" as called by thehandle_exception()
method of the Flask object when an unhandled exception occurs.The comments that follow in this issue make reference to this description.
Some Details
Flask().wsgi_app()
callsFlask().full_dispatch_request()
at line 2525 offlask/app.py
Flask().full_dispatch_request()
callsFlask().dispatch_request()
at line 1820 offlask/app.py
try/except
block ofFlask().wsgi_app()
caught the exception, handled it by callingFlask().handle_exception()
, which in turn logged it by callingFlask().log_exception()
which finally logged the error at line 1741 (seelog_exception 1741
in the first line of each log message preceding the tracebacks below).Traceback 1:
Traceback 2:
The text was updated successfully, but these errors were encountered: