@tangle-network/agent-provider-tangle 1.1.0 → 1.1.1

package/dist/tangle-environment.js

@@ -71,6 +71,8 @@ export async function sandboxInstanceAsEnvironment(box, providerName, client, de
     // Usage is measured per execution, so the log collects what runs through
     // this handle and the observation reports the newest record it holds.
     const usageLog = createExecutionUsageLog();
+    // The single destroy this handle performs, once it has been asked for.
+    let destruction;
     const terminals = capabilities.interactiveTerminal?.attach === true
         ? createTangleTerminalRegistry(box)
         : undefined;
@@ -310,7 +312,31 @@ export async function sandboxInstanceAsEnvironment(box, providerName, client, de
                         throw new Error("Tangle sandbox client cannot delete this environment");
                     assertOptionKeys(options, ["signal"], "Tangle destroy");
                     options?.signal?.throwIfAborted();
-                    await awaitWithSignal(box.delete(options), options?.signal);
+                    // One environment has more than one owner of its end. A runtime
+                    // that destroys on settle AND tears the executor down calls this
+                    // twice for the same box, and the platform refuses the second
+                    // DELETE with "A sandbox lifecycle operation is already in
+                    // progress" while the first one's cleanup still holds the
+                    // sandbox's lifecycle lease. Measured 2026-09-01 on
+                    // `sandbox-b525e04a551b`: of two concurrent deletes one answered
+                    // 200 `destroyed` and the other 409, and a third delete 0.4 s
+                    // after the 200 was still refused. That refusal cost two
+                    // completed agent turns their result
+                    // (tangle-network/agent-sdk#280), because the second destroy ran
+                    // in a caller's `finally` and its throw replaced the run's own
+                    // outcome.
+                    //
+                    // So destroy is answered once per environment and every later
+                    // caller joins that answer. This is not a retry and hides no
+                    // platform error: a delete that fails is not remembered, and the
+                    // next caller issues a real one.
+                    destruction ??= awaitWithSignal(box.delete(options), options?.signal)
+                        .then(() => undefined)
+                        .catch((error) => {
+                        destruction = undefined;
+                        throw error;
+                    });
+                    await awaitWithSignal(destruction, options?.signal);
                     options?.signal?.throwIfAborted();
                 },
             }

package/dist/tangle-exact-process-environment.js

@@ -11,6 +11,9 @@ export function sandboxInstanceAsExactProcessEnvironment(box, providerName) {
     const process = box.process;
     const fs = box.fs;
     const destroy = box.delete.bind(box);
+    // The same single delete this environment performs, once it is asked for.
+    // See the destroy() below for why one is all the platform accepts.
+    let destruction;
     return {
         id: box.id,
         provider: providerName,
@@ -177,7 +180,22 @@ export function sandboxInstanceAsExactProcessEnvironment(box, providerName) {
         async destroy(options = {}) {
             assertSignalOptions(options, "Tangle exact process destroy");
             options.signal?.throwIfAborted();
-            await awaitWithSignal(destroy(), options.signal);
+            // Deleting one sandbox twice is refused, not repeated: the platform
+            // holds a per-sandbox lifecycle lease past the first DELETE's own
+            // response while its deferred cleanup runs, so a second DELETE inside
+            // that window answers "A sandbox lifecycle operation is already in
+            // progress". Measured 2026-09-01 (issue #280) on the streaming
+            // environment, which has the same shape and the same platform route.
+            // This environment is destroyed once and later callers join that
+            // answer; a delete that fails is not remembered, so nothing hides a
+            // real error.
+            destruction ??= awaitWithSignal(destroy(), options.signal)
+                .then(() => undefined)
+                .catch((error) => {
+                destruction = undefined;
+                throw error;
+            });
+            await awaitWithSignal(destruction, options.signal);
             options.signal?.throwIfAborted();
         },
     };

package/dist/tangle-readiness.d.ts

@@ -14,18 +14,18 @@ export declare const DEFAULT_TANGLE_READY_TIMEOUT_MS = 120000;
  * A response that already reports `running` skips that wait, and `running`
  * alone is not usable: the SDK's own `waitFor` treats the target as reached
  * only when `filesystemIncarnationReadiness` is `ready`, because the box's
- * filesystem is still being built until then. So `create()` can return a box
- * that reports `running` while the platform still holds a lifecycle operation
- * on it, and the first turn lands on that lock.
+ * filesystem is still being built until then. An environment composed before
+ * that is an environment that cannot accept a turn.
  *
- * Measured against that mechanism, 2026-09-01, discovery-lab#467: one box
- * (`sandbox-97943ce9526d`) came back from `create()`, and the first
- * `environment.stream()` failed 78 seconds later with "A sandbox lifecycle
- * operation is already in progress". That string is the platform's, not the
- * SDK's, and n is 1, so the incarnation window is the mechanism this wait
- * addresses rather than a proven cause. A lifecycle lock held by a genuinely
- * concurrent operation is a different failure, and no client-side wait
- * prevents it.
+ * WHAT THIS WAIT IS NOT FOR. An earlier version of this comment claimed the
+ * wait also closed the platform's "A sandbox lifecycle operation is already in
+ * progress", and that claim is withdrawn: measured 2026-09-01 (issue #280),
+ * that refusal comes from `DELETE /v1/sandboxes/:id`, not from a turn. The
+ * platform guards exactly three routes with the per-sandbox lifecycle lease —
+ * resume, stop and delete — and the runtime path a prompt takes is not one of
+ * them, so no readiness wait here can prevent it and none is trying to. The
+ * collision is answered where it happens, in `destroy()`
+ * (`tangle-environment.ts`).
  *
  * Readiness also decides what the environment can claim. Composing an
  * environment reads the sandbox's deployment capability document once, and a

package/dist/tangle-readiness.js

@@ -15,18 +15,18 @@ export const DEFAULT_TANGLE_READY_TIMEOUT_MS = 120_000;
  * A response that already reports `running` skips that wait, and `running`
  * alone is not usable: the SDK's own `waitFor` treats the target as reached
  * only when `filesystemIncarnationReadiness` is `ready`, because the box's
- * filesystem is still being built until then. So `create()` can return a box
- * that reports `running` while the platform still holds a lifecycle operation
- * on it, and the first turn lands on that lock.
+ * filesystem is still being built until then. An environment composed before
+ * that is an environment that cannot accept a turn.
  *
- * Measured against that mechanism, 2026-09-01, discovery-lab#467: one box
- * (`sandbox-97943ce9526d`) came back from `create()`, and the first
- * `environment.stream()` failed 78 seconds later with "A sandbox lifecycle
- * operation is already in progress". That string is the platform's, not the
- * SDK's, and n is 1, so the incarnation window is the mechanism this wait
- * addresses rather than a proven cause. A lifecycle lock held by a genuinely
- * concurrent operation is a different failure, and no client-side wait
- * prevents it.
+ * WHAT THIS WAIT IS NOT FOR. An earlier version of this comment claimed the
+ * wait also closed the platform's "A sandbox lifecycle operation is already in
+ * progress", and that claim is withdrawn: measured 2026-09-01 (issue #280),
+ * that refusal comes from `DELETE /v1/sandboxes/:id`, not from a turn. The
+ * platform guards exactly three routes with the per-sandbox lifecycle lease —
+ * resume, stop and delete — and the runtime path a prompt takes is not one of
+ * them, so no readiness wait here can prevent it and none is trying to. The
+ * collision is answered where it happens, in `destroy()`
+ * (`tangle-environment.ts`).
  *
  * Readiness also decides what the environment can claim. Composing an
  * environment reads the sandbox's deployment capability document once, and a

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tangle-network/agent-provider-tangle",
-  "version": "1.1.0",
+  "version": "1.1.1",
   "description": "AgentEnvironmentProvider adapter for Tangle sandboxes",
   "type": "module",
   "license": "MIT",