The pause was saved, but stopping could not be verified. Ref

Error message

The pause was saved, but stopping could not be verified. Refresh and try Stop again if work is still running.

What it means

waitForStoppedRuns polls run states after a Stop/pause command until they confirm stopped, bounded by a deadline. If the confirmation race (poll or timeout promise) rejects — e.g. the stop-verification HTTP call fails or the deadline elapses — the original error is swallowed and replaced with this actionable message: the pause was persisted server-side, but the client could not verify the runs actually stopped.

Source

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

) {
  const getRun = options.getRun ?? heartbeatsApi.get;
  const deadline = Date.now() + (options.timeoutMs ?? 30_000);
  let remaining = [...new Set(runIds)];
  while (remaining.length > 0) {
    let states;
    let timeout: ReturnType<typeof setTimeout> | undefined;
    try {
      states = await Promise.race([
        Promise.all(remaining.map((id) => getRun(id))),
        new Promise<never>((_resolve, reject) => {
          timeout = setTimeout(
            () => reject(new Error("Stop verification timed out")),
            Math.max(0, deadline - Date.now()),
          );
        }),
      ]);
    } catch {
      throw new Error(
        "The pause was saved, but stopping could not be verified. Refresh and try Stop again if work is still running.",
      );
    } finally {
      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"
        );
      })

View on GitHub (pinned to 01ad858492)

Solutions

Refresh the issue/run list and retry Stop if work is still visibly running, as the message suggests.
Increase the verification deadline/budget if runs legitimately take long to stop.
Check the backend: confirm the pause persisted and investigate the adapter for runs that never transition to stopped.
Inspect the swallowed root cause (add logging in the catch) to distinguish timeout from poll failure.

Example fix

// before
} catch {
  throw new Error("The pause was saved, but stopping could not be verified...");
}
// after
} catch (cause) {
  console.warn("stop verification failed", cause);
  throw new Error("The pause was saved, but stopping could not be verified. Refresh and try Stop again if work is still running.", { cause });
}

Defensive patterns

Strategy: try-catch

Validate before calling

const states = await fetchRunStates(issueId);
const allStopped = states.every(s => s === "stopped");
if (!allStopped) await waitForStoppedRuns(issueId, { timeoutMs: 30_000 });

Try / catch

try {
  await waitForStoppedRuns(issueId);
} catch (e) {
  if (e instanceof Error && e.message.includes("stopping could not be verified")) {
    showNotice("Pause saved — verification pending. Refresh to confirm.");
  } else throw e;
}

Prevention

Set the verification deadline from observed run-drain times, not a fixed guess.
Log the swallowed cause inside the catch so timeouts are distinguishable from poll failures.
Reconcile state on next load: refresh run states when the user returns to the page.
Alert on adapters whose runs frequently fail to reach the stopped state.

When it happens

Trigger: Calling waitForStoppedRuns (via executeTreeControl Stop) when the deadline expires before all runs report stopped, or the underlying state-polling request rejects (network error, 4xx/5xx).

Common situations: Runs take longer than the verification window to drain (long in-flight agent turns); network hiccup mid-poll; backend accepts the pause but an agent adapter ignores it so runs never report stopped; server slow under load.

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/a0661396f9e41ff6. Report an issue: GitHub.