Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Support atomic delete-by-identity for sandboxes (no compare-and-delete primitive today)

Ouverte
#3,210 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@rodrigosetti y travaille déjà.

Depuis le 1/10/2026.

  • #1 par @rodrigosetti — ouverte

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
45/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
rust

Piste de recherche

Commencez par localiser le RPC de suppression du sandbox et ses consommateurs SDK/CLI, puis comparez l’approche de référence discutée dans #3050. Déterminez comment une précondition facultative d’identité ou de version de ressource peut être transmise lors de la suppression et comment les incohérences sont signalées. Le travail est considéré comme terminé lorsque la suppression conditionnelle est atomique, que les erreurs d’incohérence sont distinguables et que le comportement du SDK/CLI est documenté.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Problem Statement

OpenShell's sandbox delete API takes only a mutable sandbox name (openshell sandbox delete -g <gateway> <sandbox-name>). There is no way for a client to bind a delete request to a specific sandbox's immutable identity (internal ID / resource version) and have OpenShell refuse the delete if the name now resolves to a different sandbox.

This means any client-side "read identity, then delete by name" pattern has an unavoidable TOCTOU race: another OpenShell client can delete the sandbox and create a replacement under the same name between the client's identity read and OpenShell processing the delete. No amount of re-checking identity immediately before issuing the delete closes this window, because the check and the delete are not atomic.

Impact

We hit this concretely in NVIDIA/NemoClaw#10863 / NVIDIA/NemoClaw#10867: nemoclaw destroy needed a safe way to clean up a sandbox left "retained" after an interrupted onboarding. Even with a durable identity fingerprint recorded for the retained sandbox, we could not safely automate the delete, because OpenShell could not guarantee the name still pointed at the same sandbox at the moment of deletion. The fix had to make deletion of a live retained sandbox permanently fail-closed (always require a human to run the delete manually after out-of-band identity confirmation), which is a worse operator experience than a race-free automatic cleanup would be.

Proposed Design

Add an atomic delete-by-identity primitive, e.g. a resource_version / immutable ID precondition on the delete RPC (compare-and-delete semantics): the delete succeeds only if the sandbox at that name still has the identity/resource-version the caller expects, and otherwise fails with a distinguishable "identity mismatch" error rather than deleting an unexpected sandbox.

This is related to #3050 (unifying sandbox references across gateway RPCs) — a canonical sandbox reference type that includes an immutable ID could be a natural carrier for this precondition, but #3050's stated scope does not currently call out atomic/conditional delete semantics, so filing this separately to track the specific capability gap.

Acceptance Criteria

  • Sandbox delete RPC accepts an optional identity/resource-version precondition.
  • Delete fails with a distinguishable error (not a silent no-op or wrong-sandbox deletion) when the precondition does not match the current sandbox at that name.
  • Behavior documented for SDK/CLI consumers.

cc @jyaunches (raised during review of NVIDIA/NemoClaw#10867)

Langage dominant
Rust
Étoiles
15.4k
Forks
1.7k
Merge moyen
1 j 21 h
PR mergées (30 j)
366

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de NVIDIA/OpenShell

Toutes les issues de NVIDIA/OpenShell

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.