-
Notifications
You must be signed in to change notification settings - Fork 14.1k
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
chore: add 4xx error codes where applicable #21627
Conversation
Codecov Report
@@ Coverage Diff @@
## master #21627 +/- ##
===========================================
- Coverage 66.66% 55.28% -11.39%
===========================================
Files 1794 1794
Lines 68643 68677 +34
Branches 7301 7301
===========================================
- Hits 45764 37970 -7794
- Misses 21011 28839 +7828
Partials 1868 1868
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
eae8656
to
4eaa6d2
Compare
@@ -163,10 +165,12 @@ class ReportScheduleExecuteUnexpectedError(CommandException): | |||
|
|||
|
|||
class ReportSchedulePreviousWorkingError(CommandException): | |||
status = 429 |
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.
nit: idk if this is a too many request fit here but i also don't what other code fits
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.
Yeah, I agree. I wrote the same thing in the summary. I feel like ideally this wouldn't be an error.
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 don't think this will ever generate an HTTP response, this is only used on execute.py
that always run on the workers
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.
Thanks @dpgaspar. The goal is to help log the user errors vs system errors more granularly. Right now they are all getting logged as one event. Do you think that the status codes is a viable approach for logging purposes?
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.
error_type
seems more appropriate to me, similar to:
superset/superset/exceptions.py
Line 118 in 383313b
class SupersetSyntaxErrorException(SupersetErrorsException): |
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.
Thanks @dpgaspar! @john-bodley, @betodealmeida and I were talking about error_type
s as well and concluded that errors should not be raised, only exceptions, and that we can include errors with an exception, but not raise them. Do you have thoughts on that @dpgaspar?
marking this as a draft as I need to look into how this change affects the customer facing logs. |
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.
execute.py
is always used on a worker context
@@ -163,10 +165,12 @@ class ReportScheduleExecuteUnexpectedError(CommandException): | |||
|
|||
|
|||
class ReportSchedulePreviousWorkingError(CommandException): | |||
status = 429 |
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 don't think this will ever generate an HTTP response, this is only used on execute.py
that always run on the workers
message = _("Report Schedule is still working, refusing to re-compute.") | ||
|
||
|
||
class ReportScheduleWorkingTimeoutError(CommandException): | ||
status = 408 |
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.
same here, please recheck
4eaa6d2
to
3b0ceff
Compare
3b0ceff
to
df4e6f7
Compare
@@ -526,7 +527,7 @@ def next(self) -> None: | |||
return | |||
self.send() | |||
self.update_report_schedule_and_log(ReportState.SUCCESS) | |||
except CommandException as first_ex: | |||
except Exception as first_ex: |
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.
Are you changing these to more general exceptions because the CommandException does not return the full trace?
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.
rather because all of the exceptions here may not inherit from CommandException since I'm raising them all individually.
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.
LGTM!
🏷️ preset:2022.39 |
(cherry picked from commit 4417c6e)
Adding some 4xx error codes for user error, timeouts and alerts not run based on grace periods so that we can get more granular logging to differentiate between these different types of errors. Longer term fix, we probably don't need to raise and error for grace period fixes, perhaps, but instead a warning. I added a rate limit error, which seemed to be the closest that I could find. Would love any feedback on these choices.
TESTING INSTRUCTIONS
No user facing changes should be present. The logs should show 4xx errors for any user-generated reasons that an alert/report did not run.
ADDITIONAL INFORMATION