-
Notifications
You must be signed in to change notification settings - Fork 25.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
Simplify & consolidate SnapshotsService finalization #124537
base: main
Are you sure you want to change the base?
Simplify & consolidate SnapshotsService finalization #124537
Conversation
Splits up `SnapshotFinalization#doRun` into more focussed methods, brings all the other finalization-specific methods into the `SnapshotFinalization` inner class, and consolidate the exception handling.
Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination) |
SnapshotsInProgress.Entry entry = SnapshotsInProgress.get(clusterService.state()).snapshot(snapshot); | ||
final String failure = entry.failure(); | ||
logger.trace("[{}] finalizing snapshot in repository, state: [{}], failure[{}]", snapshot, entry.state(), failure); | ||
final var entry = SnapshotsInProgress.get(clusterService.state()).snapshot(snapshot); |
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.
Commenting on the SnapshotFinalization declaration / class -- can't make a comment there
WDYT of following up on this patch to shove SnapshotFinalization into its own class file? Removing the snapshot/metadata/repositoryData objects from method parameters makes their use come out of thin air, sorta, and in the scope of this file, that makes it visually much less obvious where the values are coming from.
handleFinalizationFailureBeforeUpdatingRootBlob(e); | ||
} | ||
|
||
private static ShardGenerations buildGenerations(SnapshotsInProgress.Entry snapshot, Metadata metadata) { |
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's confusing that in some methods you're keeping the parameters and in others you remove them. Is this an oversight, or did you have a thought process in mind?
public void onFailure(Exception e) { | ||
logger.error(Strings.format("unexpected failure finalizing %s", snapshot), e); | ||
assert false : new AssertionError("unexpected failure finalizing " + snapshot, e); | ||
handleFinalizationFailureBeforeUpdatingRootBlob(e); |
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.
How do we know that this is always BEFORE updating the root blob?
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.
David and I discussed offline. I better understand the benefits of the refactor as is, so I'm closing out some comments. The pre-existing tech debt is a problem, and the PR changes improve upon the situation.
Splits up
SnapshotFinalization#doRun
into more focussed methods,brings all the other finalization-specific methods into the
SnapshotFinalization
inner class, and consolidates the exceptionhandling.