-
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
API error improvements #3091
API error improvements #3091
Conversation
lib/pbench/server/api/resources/query_apis/datasets/datasets_mappings.py
Outdated
Show resolved
Hide resolved
lib/pbench/server/api/resources/query_apis/datasets/__init__.py
Outdated
Show resolved
Hide resolved
lib/pbench/test/unit/server/query_apis/test_datasets_mappings.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really want to expose internal state in the error message?
Perhaps we could use a UUID of some sort in the payload of the HTTPS response message payload, that one could search for in the logs of the server to help debugging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good but black
is unhappy with your query_apis/__ini__.py
file
While I don't think this is directly related, we would like to make it easier to find the stream of log entries leading up to an error in the log, and we have a Jira ticket that goes way back to a PR comment discussion "ages" ago. That's PBENCH-459... but this PR is a separate and more limited effort. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like some nice improvements, but I found a few things you might want to tweak.
lib/pbench/server/api/resources/query_apis/datasets/__init__.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems good. I have a concern about test_put_set_errors()
, which I hope you can allay, and a request for it as well, but it doesn't have to gate the merge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
lib/pbench/server/api/resources/query_apis/datasets/__init__.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a great step forward, but I think it would be better if APIInternalError
set the exception message to a boilerplate (including the UUID) and sent the input parameter message to the log. I think that that will simplify the places where it is used (avoiding double logging), and it will free the caller of having to sanitize the error message (which we've already concluded shouldn't convey much more than the UUID anyway).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks very nice. (Adding all the from
's is good.) I have a small question and a couple of suggestions.
PBENCH-995 The dashboard is sometimes receiving HTTP errors without `{"message"}` JSON payloads. It's not entirely clear why this is happening given the `APIAbort` logic, we could provide more useful hints in most cases and I've tried to "fill in the blanks" in places where we'd omitted the `message` parameter. In the course of this, I also added logic (mimicking that in several other places) to aggregate errors when using `PUT /datasets/metadata` to set multiple keys, when a weird error occurs in just a few. I realized that this error path wasn't *tested*, and added a unit test.
PBENCH-459 Address PBENCH-459 more expansively by A) Limiting internal system error messages to a minimum level of detail while B) Adding a UUID to the client response message and system log, supporting analysis
I'm now reporting a "canned" client response message giving away nothing but the generated UUID, while the internal log message can contain a more detailed description of the error. I moved generation of the log message from the constructor (which was weird), to the _dispatch outer block. The "partial success" cases in `/datasets/delete`, `/datasets/publish`, and in `PUT /datasets/metadata` are now *success* cases with details in the JSON response payload. I'm not 100% happy with this, either, but with the shift to content-free client responses on 500, this seems the new least worst option.
... but not really betting on it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks OK to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have two approvals; I'd appreciate @webbnh resolving conversations if he happens to be on, but I'll likely merge this by Monday anyway just to have it done!
PBENCH-995
The dashboard is sometimes receiving HTTP errors without
{"message"}
JSON payloads. It's not entirely clear why this is happening given theAPIAbort
logic, but we could provide more useful hints in most cases and I've tried to "fill in the blanks" in places where we'd omitted themessage
parameter.In the course of this, I also added logic (mimicking that in several other places) to aggregate errors when using
PUT /datasets/metadata
to set multiple keys, when a weird error occurs in just a few. I realized that this error path wasn't tested, and added a unit test.