fix(mothership): keep a started call's result after Stop, and let a blocked owner stop their run

[waleedlatif1]

Summary

Two independent run-stopping fixes, one commit each.

Stopped run's tool call (executor)

• When a second controller reached a call after Stop closed tool admission, it settled the row as "Run stopped before tool admission" with an unguarded write that also overwrote a running row. If another process's handler was still executing that call under a live lease, the call actually ran, its real result was lost (the owner's fenced write then failed), and the call read as both not-run and executed
• The closed branch now cancels only a still-pending row (completePendingAsyncToolCall); a call something already started falls through to the existing observer path and reports the owner's durable result (or lets an expired lease be revoked as lost). The common case publishes exactly the same cancellation

Stop for a blocked owner (run controls)

• Stop resolved the run's chat through the same owned-chat check as every other chat operation, which refuses a blocked account, so an owner on the access-control blocklist got 403 "User account is suspended" from Stop while their run kept going
• resolveOwnedChatContext takes an explicit allowBlockedOwner option, passed only by Stop when resolving an already-admitted run. Ownership, chat, run and scope checks are unchanged; steer, send and every other caller keep the ban check, and a Stop recorded ahead of admission still requires an unblocked account

Type of Change

• Bug fix

Testing

• executor.test.ts: a closed claim on a pending row is cancelled exactly as before; on a row another controller started, the row is not overwritten and the call returns that controller's real result (fails before)
• removal-stops-runs.integration.ts (real Postgres + Redis): a blocked owner can Stop their run and the worker receives it (fails before); the same owner is refused steer and send; another workspace member cannot Stop the run

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
docs	Skipped		Oct 16, 2026 5:24am UTC

[cubic-dev-ai]

No issues found across 5 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Turn on auto-fix | Re-trigger cubic}

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; both Stop changes preserve the relevant ownership and execution checks.

Summary

This PR fixes two Stop paths:

• Stopped runs keep the results of tool calls that already started.
• Blocked owners can stop runs that were already admitted.

No actionable issues found. Tests were inspected, not run.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Tool claim finds admission closed] --> B{Call still pending?}
  B -->|Yes| C[Save and publish cancellation]
  B -->|No| D[Wait for saved result]
  D --> E[Return result or unresolved state]
  F[Owner requests Stop] --> G[Check run owner and chat scope]
  G --> H{Run already admitted?}
  H -->|Yes| I[Allow blocked owner to Stop]
  H -->|No| J[Keep account check]

Loading

_{Reviews (1) · Last reviewed commit: "fix(mothership): let a blocked owner sto..." · Reviewed by Greptile}