Skip to content

feat(agents): resume interrupted Sandbox credential binding - #15

Draft
tee8z wants to merge 1 commit into
dev-2884-lifecycle-aware-deployfrom
dev-2884-resumable-binding
Draft

tee8z wants to merge 1 commit into
dev-2884-lifecycle-aware-deployfrom
dev-2884-resumable-binding

Conversation

@tee8z

@tee8z tee8z commented Oct 19, 2026 •

Copy link
Copy Markdown
Collaborator

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:

Launch Secret Agent container Result
Present Any check_secret(), then wait for the container to start
Missing Never started Create the Secret with the Sandbox generation and an ownerReference to the Pod, then read again
Missing Started, or restarted Error: Sandbox credentials are missing from a started session; explicit recovery is required
Missing after the 120 s deadline Never started Error: Sandbox credential binding is incomplete; retry deploy
Create fails (not AlreadyExists) Never started Remove the binding if this deploy wrote it, then error: could not create bound Sandbox credentials (<reason>); retry deploy

The 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:

  • Every launch Secret now carries BUZZ_CHECKPOINT_RESTORE_KEY. The value is empty unless the Sandbox has buzz.block.xyz/restore-checkpoint.
  • The value comes from the Sandbox, never from the request.
  • The key name is part of every launch fingerprint, so a recovered Sandbox matches later ordinary deploys.
  • Fingerprints also 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_fixtures 5 passed.
  • New fake-apiserver tests: 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

  • The ignored test live_controller_reuses_scopes_and_refuses_lost_workspaces needs the kind-remote-agent-check cluster. It was not run.
  • No code sets restore-checkpoint yet; the recovery PR adds it.
  • Temporary glue:
    • The fake-test section header says "deploy paths". The stop PR changes it.
    • The module doc and fake_scope() do not mention recovery. The recovery PR changes them.
  • Buzz AGENTS.md requires a human to test the change before it leaves draft.

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
tee8z force-pushed the dev-2884-resumable-binding branch from 2ed384b to 089bf4f Compare October 19, 2026 23:28
@coderabbitai

coderabbitai Bot commented Oct 19, 2026

Copy link
Copy Markdown

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Comment @coderabbitai help to get the list of available commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant