The pause was saved, but work is still stopping. Try Stop ag

Error message

The pause was saved, but work is still stopping. Try Stop again if it continues.

What it means

waitForStoppedRuns polls run cancellation states after a Stop/Pause action and throws this when the deadline expires while at least one run has not reached an acknowledged cancellation state. The pause was persisted, but the underlying agent runs are still winding down, so the UI warns the operator to retry Stop if the runs never settle. It is a deliberate timeout guard against hung or slow-to-cancel runs.

Source

Thrown at ui/src/lib/wait-for-stopped-runs.ts:53

      clearTimeout(timeout);
    }
    remaining = states
      .filter((run) => {
        if (LIVE_STATUSES.has(run.status)) return true;
        if (!("runtimeMode" in run) || run.runtimeMode !== "native" || run.status !== "cancelled")
          return false;
        const cancellation = run.resultJson?.nativeCancellation;
        return (
          !cancellation ||
          typeof cancellation !== "object" ||
          !("dispatchState" in cancellation) ||
          cancellation.dispatchState !== "acknowledged"
        );
      })
      .map((run) => run.id);
    if (remaining.length === 0) return;
    if (Date.now() >= deadline) {
      throw new Error(
        "The pause was saved, but work is still stopping. Try Stop again if it continues.",
      );
    }
    await new Promise((resolve) =>
      setTimeout(resolve, options.intervalMs ?? 500),
    );
  }
}

View on GitHub (pinned to 01ad858492)

Solutions

Wait a few seconds and trigger Stop again — the message explicitly instructs this and the second pass usually observes acknowledged states.
Check the adapter/process backing the still-stopping runs for hangs (stuck child process, dead adapter) and restart it.
Increase the polling budget passed via options (deadline/intervalMs) if runs legitimately take long to stop.
Inspect the run's cancellation.dispatchState in the DB/API to see whether it is queued vs stuck, and manually force-cancel if the control plane is wedged.

Example fix

// before
const remaining = runs.filter((run) => run.cancellation.dispatchState !== "acknowledged");
if (remaining.length === 0) return;
if (Date.now() >= deadline) {
  throw new Error("The pause was saved, but work is still stopping. Try Stop again if it continues.");
}
// after (caller-side guard: retry once instead of surfacing an error)
try {
  await waitForStoppedRuns(runs, options);
} catch {
  await triggerStop();
  await waitForStoppedRuns(runs, { ...options, deadline: Date.now() + 15_000 });
}

Defensive patterns

Strategy: retry

Validate before calling

const stillStopping = runs.some((r) => r.cancellation.dispatchState !== "acknowledged");
if (!stillStopping) return; // safe to proceed

Type guard

const isAcknowledged = (r: { cancellation: { dispatchState: string } }) =>
  r.cancellation.dispatchState === "acknowledged";

Try / catch

try {
  await waitForStoppedRuns(runs, options);
} catch (e) {
  if (e.message.includes("still stopping")) {
    await triggerStop();
    await waitForStoppedRuns(runs, { ...options, deadline: Date.now() + 15_000 });
  } else throw e;
}

Prevention

Check all runs' cancellation.dispatchState before expecting Stop to be instantaneous.
Pass a generous deadline/intervalMs when many runs are stopping concurrently.
Monitor adapter process health — hung adapters are the usual cause of never-acknowledged cancels.

When it happens

Trigger: Calling waitForStoppedRuns (via executeTreeControl or result) when, after the deadline elapses, some run's cancellation.dispatchState !== "acknowledged" — i.e. remaining.length > 0 at timeout.

Common situations: An agent adapter is slow to acknowledge a cancel signal; an adapter process is hung or unresponsive; many concurrent runs are stopping at once and exceed the polling window; a run is stuck in a dispatch state that never reaches acknowledged.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Related errors

AI-assisted analysis of paperclipai/paperclip@01ad858492 (2026-09-10). Data as JSON: /api/errors/8c943418e4791486. Report an issue: GitHub.