-
Notifications
You must be signed in to change notification settings - Fork 2
Enhance error handling and refactor API request logic #27
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
Conversation
In the first line looks like there the message is caused by is a bug in CBRAIN, IMHO you should make clear that error message is from CBRAIN and not your client. I submitted a PR for that CBRAIN bug a few days ago, and it should be reviewed soon, but something like that potentially can happen again when new bug is introduced or discovered. Maybe add a prefix 'Server error:', 'API Endpoint encountered error:' @prioux @dlq @natacha-beck ? In the second line the message seems tractable, IMHO |
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.
Based on your example, I think even if we extract the detailed server message, we should still communicate the status code. More, for less savvy users, we can also provide a short description of what it means, something akin
Server error (5xx): ...
Validation error (422): ...
Oh, do you want to add status code like -
|
Not sure I think Record not Found is 404 ( a client/user side error). All the 5xx (500 - 505) codes are some server side errors. Can we keep this distinction? |
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 preferred the older, more user-tailored error messages, but this way - returning only server errors - might be easier to maintain and works well for advanced users.
There are a few cases where a server error message isn’t returned, but that doesn’t bother me much.
I do feel that sometimes the wording could be slightly improved. For example, instead of:
Try with authorized access
it would be clearer to show:
Error: Access denied. Please log in using authorized credentials.
Tokens work as long as the server says they work.
Enhance error handling and refactor API request logic across multiple modules.
Improved HTTP error responses in
cli_utils.py
, streamlined data fetching indata
modules, and removed redundant error handling.Updated command argument parsing in
main.py
to ensure required fields are enforced.Cleaned up interactive prompts in
tags.py
and adjusted formatting in output functions.Fixes: #5