ateletpb: split the Restore snapshot source from the checkpoint destination - #1602
Open
Dmitry Berkovich (dberkov) wants to merge 3 commits into
Open
ateletpb: split the Restore snapshot source from the checkpoint destination#1602Dmitry Berkovich (dberkov) wants to merge 3 commits into
Dmitry Berkovich (dberkov) wants to merge 3 commits into
Conversation
RestoreRequest borrowed ExternalCheckpointConfiguration — a write destination — for the snapshot it reads, leaving read-side attributes of a restore source no place to live. Split the restore arm into its own ExternalRestoreConfiguration; the oneof's type change is wire-compatible (snapshot_uri keeps field number 1, and old peers decode the message as before). base_config supersedes golden_snapshot_uri, typing the DATA_ON_GOLDEN base as a restore source too. The old field stays until both components roll — callers set both and atelet prefers base_config — and is removed (and reserved) in a follow-up. Pure restructuring: no caller sets base_config yet, nothing reads it, and the wire bytes of every current request are unchanged.
Prefer RestoreRequest.base_config and fall back to the superseded golden_snapshot_uri, so ateapi and atelet can roll in either order. A transitional caller sets both; validation requires them to agree, and a base snapshot of either spelling is rejected outside SNAPSHOT_SCOPE_DATA_ON_GOLDEN scope.
Set RestoreRequest.base_config on both DATA_ON_GOLDEN resume paths (an external data snapshot and a local pause checkpoint combining with the golden), alongside the superseded golden_snapshot_uri it duplicates: an atelet from before base_config reads only the old field, so the dual-write lets the two components roll in either order. The old field and this duplication go away together in a follow-up once both sides have rolled.
Dmitry Berkovich (dberkov)
requested a review
from Julian Gutierrez Oschmann (juli4n)
September 10, 2026 22:48
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
1 participant
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.
Pure refactoring of the atelet Restore API, preparing for the node-local snapshot cache (#690, #1551) without any behavior change:
RestoreRequestgets its own external snapshot source type, so read-side attributes of a restore source have a home — today the URI, next (in the M2 cache work) a sharing/cacheability property set by the control plane.Three commits, each buildable and tested:
ateletpb: give Restore its own external snapshot source message—ExternalRestoreConfigurationreplacesExternalCheckpointConfigurationinRestoreRequest's config oneof. The type change is wire-compatible:snapshot_urikeeps field number 1, so old peers decode the message exactly as before (the constraint is documented on the field).base_config(field 16) supersedes the top-levelgolden_snapshot_uristring, typing the DATA_ON_GOLDEN base as a restore source too — astring → messagechange is not wire-compatible, hence the new field number and the transition below.CheckpointRequestis untouched.atelet: read the restore base snapshot from base_config— dual-read: one helper prefersbase_configand falls back to the superseded field, so an old ateapi keeps working. Validation requires a transitional caller's two fields to agree and rejects a base snapshot outsideSNAPSHOT_SCOPE_DATA_ON_GOLDEN.ateapi: send the restore base snapshot as base_config— dual-write on both DATA_ON_GOLDEN resume paths, so an old atelet keeps working. A new functional test drives the golden-data resume end to end (onCommit DATA + onResume.fromData GOLDEN → suspend → resume) and pins both fields set and agreeing on the wire.Rollout: safe in either order — new ateapi → old atelet ignores the unknown fields and reads
golden_snapshot_uri; old ateapi → new atelet falls back to it. A follow-up PR removes (and reserves) field 12 and drops the dual read/write once both components have rolled.Tested: full ateapi + atelet suites including the controlapi functional tests; gofmt, golangci-lint, boilerplate clean.
🤖 Generated with Claude Code