-
-
Notifications
You must be signed in to change notification settings - Fork 202
Remove hardcoded rule for handling erroneous status codes differently #1687
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
Changes from 18 commits
4a2762d
3c0f4d1
5abae50
bc78da9
01dbe61
c7c5cbd
0782fff
bd5c85f
1ef9af0
955ce69
5cf4fb5
a25ea18
0c5fe55
c266f26
171ed3f
c6988b4
471461a
98f3dcf
6e24249
f565686
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -105,6 +105,8 @@ impl RetryExt for ErrorKind { | |
| }) = self.github_error() | ||
| { | ||
| source.should_retry() | ||
| } else if let Self::RejectedStatusCode(StatusCode::TOO_MANY_REQUESTS) = self { | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And not quite sure if this the optimal approach
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, not sure about this. Doesn't that mean: "if a user decided to reject a 429 Too Many Requests status code, you should still retry"? To me, that sounds like the user should be in control here; if they decided to consider 429s as hard errors, so be it. 😉 That should be the final answer, and we shouldn't retry. So I'd remove that condition and see where it breaks. (Unless I'm misunderstanding.)
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So actually I think we should leave it like this. Otherwise it means that lychee will never retry requests when a 429 occurs. The reason I noticed it in the first place was because without these lines there are test failures. If we don't keep these two lines that would mean that
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds good. Can we add a comment to explain that behavior. I'm sure I'll forget why it's there otherwise. 😅 |
||
| return true; | ||
| } else { | ||
| false | ||
| } | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.