Skip to content
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

Merged
merged 7 commits into from
Dec 12, 2022
Merged

Conversation

dbutenhof
Copy link
Member

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, 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 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.

@dbutenhof dbutenhof added bug Server API Of and relating to application programming interfaces to services and functions labels Nov 30, 2022
@dbutenhof dbutenhof self-assigned this Nov 30, 2022
@portante portante added this to the v0.72 milestone Nov 30, 2022
Copy link
Member

@portante portante left a 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.

Copy link
Member

@npalaska npalaska left a 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

@dbutenhof
Copy link
Member Author

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.

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.

siddardh-ra
siddardh-ra previously approved these changes Dec 1, 2022
Copy link
Member

@siddardh-ra siddardh-ra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good 👍

webbnh
webbnh previously approved these changes Dec 1, 2022
Copy link
Member

@webbnh webbnh left a 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/__init__.py Outdated Show resolved Hide resolved
lib/pbench/server/api/resources/query_apis/__init__.py Outdated Show resolved Hide resolved
lib/pbench/test/unit/server/test_datasets_metadata.py Outdated Show resolved Hide resolved
lib/pbench/server/api/resources/datasets_metadata.py Outdated Show resolved Hide resolved
lib/pbench/test/unit/server/test_datasets_metadata.py Outdated Show resolved Hide resolved
@dbutenhof dbutenhof dismissed stale reviews from webbnh and siddardh-ra via f7d0287 December 1, 2022 21:47
webbnh
webbnh previously approved these changes Dec 2, 2022
Copy link
Member

@webbnh webbnh left a 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.

riya-17
riya-17 previously approved these changes Dec 2, 2022
npalaska
npalaska previously approved these changes Dec 2, 2022
Copy link
Member

@npalaska npalaska left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

siddardh-ra
siddardh-ra previously approved these changes Dec 5, 2022
@dbutenhof dbutenhof dismissed stale reviews from riya-17 and webbnh via 2442189 December 5, 2022 21:18
@dbutenhof dbutenhof marked this pull request as ready for review December 5, 2022 21:48
Copy link
Member

@webbnh webbnh left a 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).

lib/pbench/server/api/resources/__init__.py Outdated Show resolved Hide resolved
lib/pbench/server/api/resources/__init__.py Outdated Show resolved Hide resolved
lib/pbench/server/api/resources/__init__.py Show resolved Hide resolved
lib/pbench/server/api/resources/__init__.py Outdated Show resolved Hide resolved
lib/pbench/server/api/resources/datasets_metadata.py Outdated Show resolved Hide resolved
lib/pbench/server/api/resources/__init__.py Outdated Show resolved Hide resolved
lib/pbench/test/unit/server/conftest.py Outdated Show resolved Hide resolved
lib/pbench/test/unit/server/conftest.py Outdated Show resolved Hide resolved
webbnh
webbnh previously approved these changes Dec 9, 2022
Copy link
Member

@webbnh webbnh left a 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.

lib/pbench/server/api/resources/__init__.py Show resolved Hide resolved
lib/pbench/server/api/resources/__init__.py Show resolved Hide resolved
lib/pbench/test/unit/server/conftest.py Outdated Show resolved Hide resolved
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.
Copy link
Member

@webbnh webbnh left a 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.

Copy link
Member Author

@dbutenhof dbutenhof left a 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!

@dbutenhof dbutenhof merged commit b33985f into distributed-system-analysis:main Dec 12, 2022
@dbutenhof dbutenhof deleted the error branch December 12, 2022 14:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API Of and relating to application programming interfaces to services and functions bug Server
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants