paperclipai/paperclip · error · Error
The stop was requested, but stopping could not be verified…
Error message
The stop was requested, but stopping could not be verified. Refresh and try Stop again if work is still running.
What it means
`waitForStoppedRuns` races per-run stop polling against a deadline; if the underlying wait/poll promise rejects (e.g. the internal 'Stop verification timed out' timer or a polling request failure), it replaces the error with this user-facing message telling the operator to refresh and retry Stop. The stop request was dispatched but the UI could not confirm the runs actually stopped.
Solutions
- Refresh the board and check run states; issue Stop again if work is still running.
- Check server logs for cancellation dispatch/acknowledgement failures for the affected run ids.
- If this recurs, increase the verification deadline/interval options passed to waitForStoppedRuns.
Example fix
// before
await waitForStoppedRuns(runIds);
// after
try { await waitForStoppedRuns(runIds, { deadlineMs: 30000, intervalMs: 500 }); }
catch (e) { showToast(String(e.message)); } Defensive patterns
Strategy: try-catch
Validate before calling
const states = await fetchRunStates(ids); if (states.every(isStopped)) return; // already stopped
Type guard
const isStopped = (r: RunState) => r.cancellation?.dispatchState === 'acknowledged' || r.status === 'stopped';
Try / catch
try { await waitForStoppedRuns(ids); } catch (e) { showToast(e.message); /* advise refresh + retry Stop */ } Prevention
- Verify runs are already stopped before calling.
- Use generous deadlines for long-running agents.
- Surface the error verbatim so users follow the refresh/retry guidance.
When it happens
Trigger: Runs remain non-stopped past the deadline because the internal timeout fired, or a state-poll request threw while verifying cancellation acknowledgement.
Common situations: Runner/agent process ignoring cancellation signals; backend slow to transition run dispatch state to acknowledged; network hiccup during the verification poll window.
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
- The stop was requested, but work is still stopping. Try…
- CreateOS sandbox did not reach
- The pause was saved, but stopping could not be verified…
- The pause was saved, but work is still stopping. Try Stop…
- --agent-name cannot be empty.
AI-assisted analysis of paperclipai/paperclip@3f1d897a7c (2026-09-18).
Data as JSON: /api/errors/b50157b70f514ea4.
Report an issue: GitHub.
Appendix: 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 stop was requested, 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;
const adapterCancellation = run.resultJson?.executionCancellation;
if (adapterCancellation && typeof adapterCancellation === "object"
&& "state" in adapterCancellation && adapterCancellation.state !== "acknowledged") 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) ||View on GitHub (pinned to 3f1d897a7c)