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
vtadmin onlineddl endpoints #15114
vtadmin onlineddl endpoints #15114
Changes from 10 commits
46b390c
12debc6
77de886
dfde40d
2a9c7c5
decd79f
6e40621
2f1a0c1
c60d8d9
84225e8
77fd6bf
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
Any reason not to use an
errgroup
? Seems like it would be a perfect fit -- making the code simpler to read and ending earlier.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.
the main difference between
errgroup
and this pattern is the following (emphasis mine):we would be losing information by switching, as we currently collect all errors. and (as i understand it)
errgroup
doesn't actually terminate other goroutines early if one returns an error, it just limits the amount of error information you get, so it doesn't end up ending earlierThere 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, it doesn't forcefully end anything AFAIUI — it cancels the context (assuming errgroup.WithContext() was used) so it should cause things to end earlier assuming that the errgroup's context is used by calls within the errgroup's Go function AND that the code executed in the goroutines check for context cancellation. Even so, the point about losing error information is valid. I was just curious -- the current code is fine.
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.
IMO it's worth a safety check that
requestsByCluster[c.ID]
is not nil — even though it should not be. But we don't want to crash vtadmin if something odd happens, right? Perhaps we're recovering elsewhere though.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.
good call
as to your second question, we do have error recovery in both the http and grpc stacks: