vouchfx-mcp GitHub
Documentation / VFX-E-1507

VFX-E-1507

Title

RunNotCancellable

Explanation

cancel_run was asked to stop a run that is genuinely in flight, but this server process is not the one running it — so there is no channel to signal it through, and nothing was cancelled.

This is not "the run does not exist" (that is VFX-E-1505) and not "the run is already over" (that is cancel_run's ordinary status: "already_finished" answer, which is a success). The run is running; this server simply cannot reach it.

Read the message, not just the code. All this server can establish directly is whether it is running the named run — and, separately, whether the workspace's run lock is held by something. The lock answers per workspace, not per run, so a held lock never on its own proves that another process is running this run. The message names whichever of the three situations below the server could actually establish, and hedges where it could not:

  • Another server process is running it. Two MCP server processes can share one --workspace, and only one of them holds a given run. Runs are serialized per workspace by a file lock at <outputDir>/.lock, and that lock is a kernel-held file handle carrying no payload — it is what makes mutual exclusion work, and it is also why one process cannot send a message through it to another. There is deliberately no side-channel: building one would be a second cancellation path competing with the graceful stop run_suite already performs, which is exactly what this server refuses to do.
  • The run has already finished here and its completing record was lost. Either it is being written right now — a very short window at the end of every run, after which the identical call returns already_finished — or the write genuinely failed, in which case the server announced "produced a verdict, but recording its completion failed" on its stderr and the entry will read running until its run directory is removed.
  • This server is busy with a different run. Its own run holds the workspace lock, so the probe found the lock held and learned nothing at all about the run you named — that entry may be live elsewhere, or residue. The message says so and points you at list_runs: cancel the run this server is running if that is what you meant, or wait for it to finish and ask again, when the probe can answer for your entry.

The condition clears on its own in every case, which is why this error is retryable: when whatever holds the workspace finishes, the identical cancel_run call answers already_finished, or VFX-E-1508 if the entry turns out to have been residue all along.

If instead the entry says running but no process is running it — the residue a server killed mid-run leaves behind — you get VFX-E-1508, not this code.

Common causes

  • Two MCP server processes are configured against the same --workspace, and the run was started by the other one.
  • An editor or agent restarted its MCP server while a run was in flight; the surviving run belongs to the old process.
  • cancel_run raced the end of the run and arrived while the completing registry write was still in progress.
  • The run's completing registry write failed (a full disk, a permissions change mid-run), so its entry still reads running although nothing is running it.
  • This server is running a different run, whose workspace lock masks the probe that would otherwise have settled the entry you asked about.
  • A runId was carried over from a different session or a different host and points at a run this server never started.

Fixes

  • Read the error message: it names which of those situations this server could establish, and hedges only where it genuinely could not tell.
  • Cancel the run from the server process that started it — that is the only process able to stop it gracefully.
  • If this server is busy with another run, call list_runs and cancel that runId if it is the one you meant.
  • Or simply wait: the run finishes on its own, and cancel_run then reports already_finished rather than an error.
  • Poll get_run_status until the status is terminal (completed or cancelled) instead of retrying the cancellation.
  • Check the server's stderr for a "produced a verdict, but recording its completion failed" line, which means the entry will never become terminal on its own.
  • If you did not intend to share a workspace, give each server process its own --workspace so runs and their locks cannot overlap.
  • Retry once after a moment if you believe the run was about to finish anyway — the completing-write window is very short.