Repository navigation
Conversation
A deploy that bound the Sandbox to its first Pod but never wrote the launch Secret used to strand the session. The next deploy now finishes the binding while the container has not started, with the Sandbox's own generation and an owner reference to that Pod. When the Secret write fails, the deploy hands its first-Pod binding back (CAS) so a retry starts clean; a started session without credentials still requires explicit recovery. Every launch Secret now carries BUZZ_CHECKPOINT_RESTORE_KEY (empty unless a recovered session restores a checkpoint). The value comes from the Sandbox, never the request, so a resumed binding keeps the restore its Sandbox was created with. The key is part of every launch fingerprint; Sandboxes created before it existed are still reused. Signed-off-by: Tee8z <tee8z@protonmail.com>
tee8z
force-pushed
the
dev-2884-resumable-binding
branch
from
October 19, 2026 23:28
2ed384b to
089bf4f
Compare
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: true
Comment |
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
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.
A deploy can bind the Sandbox to its first Pod (
initial-pod-uid) and then fail before it writes the launch Secret.Before this PR, that Sandbox stayed bound with no credentials, and every later deploy failed.
Now the next deploy finishes the binding while the agent container has not started.
Outcomes for a Pod that matches
initial-pod-uid:check_secret(), then wait for the container to startSandbox credentials are missing from a started session; explicit recovery is requiredSandbox credential binding is incomplete; retry deployAlreadyExists)could not create bound Sandbox credentials (<reason>); retry deployThe binding removal uses a resourceVersion compare-and-swap (CAS) write and is best effort.
The error carries only the apiserver reason, because the message could echo credentials.
Restore key launch contract:
BUZZ_CHECKPOINT_RESTORE_KEY. The value is empty unless the Sandbox hasbuzz.block.xyz/restore-checkpoint.Fingerprintsalso accepts the legacy fingerprint without the key, so existing Sandboxes are still reused.Stack
Position 9 of 20 in the DEV-2884 Buzz stack. Base: #14. Next: #16.
Validation
cargo fmt --check -p buzz-backend-kubernetes: pass.cargo clippy -p buzz-backend-kubernetes --all-targets -- -D warnings: pass.cargo test -p buzz-backend-kubernetes: lib 12 passed; bin 172 passed, 1 ignored;wire_fixtures5 passed.a_bound_session_without_its_secret_is_resumed,a_secret_create_failure_unbinds_and_the_retry_succeeds,the_restore_key_is_fingerprinted_by_name_not_value,a_sandbox_from_before_the_restore_key_is_still_reused.Limits
live_controller_reuses_scopes_and_refuses_lost_workspacesneeds thekind-remote-agent-checkcluster. It was not run.restore-checkpointyet; the recovery PR adds it.fake_scope()do not mention recovery. The recovery PR changes them.