Skip to content
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

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

DaveCTurner
Copy link
Contributor

@DaveCTurner DaveCTurner commented Mar 11, 2025

Splits up SnapshotFinalization#doRun into more focussed methods,
brings all the other finalization-specific methods into the
SnapshotFinalization inner class, and consolidates the exception
handling.

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.
@elasticsearchmachine elasticsearchmachine added the Team:Distributed Coordination Meta label for Distributed Coordination team label Mar 11, 2025
@elasticsearchmachine
Copy link
Collaborator

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);
Copy link
Contributor

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) {
Copy link
Contributor

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);
Copy link
Contributor

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?

Copy link
Contributor

@DiannaHohensee DiannaHohensee left a 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Coordination/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs >refactoring Team:Distributed Coordination Meta label for Distributed Coordination team v8.19.0 v9.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants