@pify/shell-background 0.4.1 → 0.4.2

package/README.md

@@ -34,7 +34,7 @@ shell_kill { id: "bg-2" }                # stop it and its whole process tree
 
 ## Delivery, and the headless caveat
 
-When a backgrounded command finishes in an **interactive** session, its result is pushed into the conversation as the next turn — you do not have to poll. Under headless `pi -p` there is nothing to deliver into (the session tears down when the prompt resolves), so **auto-background is disabled there** and only explicit `background: true` applies; collect it within the same turn with `shell_status { id, wait: N }`, which blocks (up to `N` seconds, 0–300) until the command finishes rather than returning immediately. This is the same delivery rule the rest of the suite lives by.
+When a backgrounded command finishes in an **interactive** session, its result is pushed into the conversation as the next turn — you do not have to poll. Under headless `pi -p` there is nothing to deliver into (the session tears down when the prompt resolves), so **auto-background is disabled there** and only explicit `background: true` applies; collect it within the same turn with `shell_status { id, wait: N }`, which blocks (up to `N` seconds, 0–300) until the command finishes rather than returning immediately. This is the same delivery rule the rest of the suite lives by. A finish that a `shell_status` wait returns is collected there and not delivered a second time, so the model never spends a turn acknowledging a result it has just reported.
 
 ## How it works
 

package/extensions/shell-background.ts

@@ -229,6 +229,18 @@ export default function shellBackground(pi: ExtensionAPI) {
     );
   }
 
+  /**
+   * Jobs a shell_status wait is blocking on, by id. Seen on pi 1.0.4 with the
+   * TUI captured: a foreground command auto-backgrounds at 30s, the model
+   * waits on it with shell_status, the exit handler delivers the finish as a
+   * follow-up in the same instant the wait returns it, and the model spends a
+   * whole extra turn acknowledging a result it had just reported. While a
+   * wait is active the finish is returned there and marked collected; the
+   * delivery path stands down.
+   */
+  const waiters = new Map<string, number>();
+  const awaited = (job: Job): boolean => (waiters.get(job.id) ?? 0) > 0;
+
   /** Deliver a finished background job into the conversation, once. */
   function scheduleDelivery(job: Job, exit: Promise<unknown>): void {
     exit
@@ -241,7 +253,7 @@ export default function shellBackground(pi: ExtensionAPI) {
           registry?.persist(job);
           return;
         }
-        if (job.delivered) return;
+        if (job.delivered || awaited(job)) return;
         job.delivered = true;
         registry?.persist(job);
         deliver(job);
@@ -522,7 +534,22 @@ export default function shellBackground(pi: ExtensionAPI) {
       const waitSec = Number.isFinite(params.wait) ? Math.min(300, Math.max(0, Math.floor(params.wait as number))) : 0;
       if (waitSec > 0 && job.status === "running") {
         const deadline = Date.now() + waitSec * 1000;
-        while (job.status === "running" && Date.now() < deadline && !sig?.aborted) await sleep(250);
+        waiters.set(job.id, (waiters.get(job.id) ?? 0) + 1);
+        try {
+          while (job.status === "running" && Date.now() < deadline && !sig?.aborted) await sleep(250);
+        } finally {
+          waiters.set(job.id, Math.max(0, (waiters.get(job.id) ?? 1) - 1));
+        }
+      }
+      if (sig?.aborted) {
+        // The model never sees an aborted tool result. If the job finished
+        // while this wait held the delivery path back, deliver it now.
+        if (isFinished(job) && !job.delivered) {
+          job.delivered = true;
+          registry.persist(job);
+          deliver(job);
+        }
+        return { content: [{ type: "text", text: `shell_status ${job.id}: wait aborted` }], details: { id: job.id }, isError: true };
       }
       // Reading a finished job marks it collected so it will not also be
       // delivered unasked. A still-running poll must never do this: setting
@@ -614,7 +641,7 @@ export default function shellBackground(pi: ExtensionAPI) {
           }
         }
         if (job.status === "running") anyRunning = true;
-        else if (!job.delivered) {
+        else if (!job.delivered && !awaited(job)) {
           job.delivered = true;
           registry.persist(job);
           deliver(job);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pify/shell-background",
-  "version": "0.4.1",
+  "version": "0.4.2",
   "description": "Long-running bash goes async: background: true launches detached, and any command still running after 30s auto-backgrounds and delivers its result when it finishes",
   "keywords": [
     "pi-package",

package/src/format.ts

@@ -17,12 +17,11 @@ function duration(job: Job): string {
   return secs(Math.max(0, end - job.startedAt));
 }
 
-/** `[bg-1 · done · exit 0 · 4.2s]` — the one-line header every result carries. */
+/** `[bg-1 · done · exit 0 · 4.2s]` — the one-line header every result carries. A running job has no verdict yet: `[bg-1 · running · 13.2s]`. */
 export function header(job: Job): string {
+  if (job.status === "running") return `[${job.id} · running · ${duration(job)}]`;
   const verdict =
-    job.status === "running"
-      ? "running"
-      : job.status === "orphaned"
+    job.status === "orphaned"
         ? "orphaned (another session)"
         : job.signal
           ? `signal ${job.signal}`