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.
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
Do not retry indefinitely if service is gone #5789
Do not retry indefinitely if service is gone #5789
Changes from all commits
fad5da9
d674024
ae36201
afade17
2d71a87
ff39150
c76e6fe
0a45871
4bf4bf5
9e8fcc1
0baa9c8
6917f42
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
It looks like when you call
run
inside thecreate_region
future insideensure_region_in_dataset
, there is aretry_notify
call around thecreate_region
future. This creates two backoff loops rather than one, and seems like a really easy mistake to make. Instead, what if we didn't actually call retry instead ofrun
here but relied on the outer retry loop. I think that would simplify this a lot as well, as now you wouldn't have to worry about the progenitor errors. The outer loop would call a future that only does the gone check once and returns an error, rather than looping.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.
In this case, the double backoff looping was intentional: the outer retry (in nexus/src/app/crucible.rs) is to poll until a desired state change, and the inner retry (in common/src/progenitor_operation_retry.rs) is to paper over transient network problems. I think I still like this separation, though I don't grok the simplification you're referring to yet. Going to hack around with this.
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.
If this makes sense, and your hacking didn't yield anything, I'm fine leaving it as is for now.
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.
style nit, take it or leave it: this could be a bit more concise as:
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.
In this case, I prefer the more explicit style, but thanks :)