translate Retry to Base.retry#548
Merged
Merged
Conversation
Member
Author
|
Going to check on CI: bors try |
Contributor
tryBuild failed: |
Member
Author
|
bors try |
Contributor
tryBuild failed: |
Member
Author
|
bors try |
Contributor
tryBuild failed: |
Member
Author
|
bors try |
ericphanson
commented
May 11, 2022
| @@ -0,0 +1 @@ | |||
| style="blue" | |||
Member
Author
There was a problem hiding this comment.
This lets me use "format" command in VSCode
Contributor
tryBuild failed: |
Member
Author
|
bors try |
Contributor
Member
Author
|
bors try |
Contributor
tryBuild failed: |
Member
Author
|
bors try |
Contributor
omus
reviewed
May 19, 2022
Co-authored-by: Curtis Vogt <curtis.vogt@gmail.com>
Member
Author
|
bors try |
Contributor
tryBuild failed: |
Member
Author
|
bors try |
Contributor
tryBuild failed: |
This reverts commit 6a96fae.
Member
Author
|
bors try |
Contributor
Member
Author
|
Ok! I don't really want to do more formatting changes since it's kind of pain to get it through Bors again. Are there any other changes we should make here? Or is it good to go? |
Co-authored-by: Curtis Vogt <curtis.vogt@gmail.com>
Member
Author
|
bors r+ |
Contributor
bors Bot
added a commit
that referenced
this pull request
Mar 20, 2023
549: Add debug logging messages on retry r=mattBrzezinski a=ericphanson Closes #514 Based on #548 The logging messages are structured so the string is a human-readable summary of the message, and then the fields are more structured for later analysis, e.g. `retry::Bool`, `reason::String`, etc. Additionally, the id of the log message will be useful for aggregation. Co-authored-by: Eric Hanson <5846501+ericphanson@users.noreply.github.com> Co-authored-by: Matt Brzezinski <matt.brzezinski@beacon.bio>
bors Bot
added a commit
that referenced
this pull request
Mar 20, 2023
549: Add debug logging messages on retry r=mattBrzezinski a=ericphanson Closes #514 Based on #548 The logging messages are structured so the string is a human-readable summary of the message, and then the fields are more structured for later analysis, e.g. `retry::Bool`, `reason::String`, etc. Additionally, the id of the log message will be useful for aggregation. Co-authored-by: Eric Hanson <5846501+ericphanson@users.noreply.github.com> Co-authored-by: Matt Brzezinski <matt.brzezinski@beacon.bio>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Suggested in #542 (comment)
I'm not sure we should merge this as-is, because before we could do immediate retries OR delay retries, and now we can only do delay retries.
I'm also not 100% sure the delay amounts are the same.The functional approach is nicer than the macro approach though in my opinion,
since the retries don't need to be literals. So we could let folks request more retries on a per-request basis, or even put it in the Backend struct.edit 1: Retry.jl expands to a for-loop, so non-literals are OK. I thought it unrolled the loop.
edit 2: the delay amounts are definitely not the same, but that's a good thing- now we copy the upstream recommendation from https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html. In particular, putting a cap of 20s means we can increase the retries further without danger, xref #550 (we can't do that with Retry.jl since the retries are hard-coded with no cap and get too big- ref #543 (comment)).
12 May update:
I'm now in favor of merging this, because I want to get in #550. The first few retries are pretty short, e.g.
So I think having a short delay instead of an immediate retry in a few cases is probably OK. Also, the AWS docs don't talk about non-delayed retries, they seem to only do delayed retries.