fix(cloud-agent-next): own the stop cleanup deadline per hop

[eshurakov]

Summary

interruptSession could acknowledge an interruption while interrupting nothing. The cause was a deadline that one clock sets and a different clock enforces.

cleanupDeadlineAt is minted in the Worker as Date.now() + SANDBOX_CONTROL_CLEANUP_TIMEOUT_MS (10_000), then validated against another clock at two hops:

1. admitSessionStop in the Durable Object, reached through admitControlStop;
2. parseScopedStopMaintenance in SandboxControl, which returns undefined and makes SandboxControl.request throw Invalid scoped Stop maintenance request.

Because the minted value already contained the timeout, the upper bound at each hop (deadline <= now + TIMEOUT) left room only for the mint-to-validate latency — it reduced to workerNow > doNow. Any positive skew between the two machines rejected the stop as Stop cleanup deadline is invalid. At hop 1 that surfaced as success: false; at hop 2 the throw was swallowed by progressSessionStop's bare catch { continue; }. Either way the caller saw an accepted request and a session that never aborted.

Both hops now reject only an already-elapsed window and otherwise accept and saturate to now + SANDBOX_CONTROL_CLEANUP_TIMEOUT_MS, so the clock that enforces the bound is the clock that sets it. Request identity (sameRequest) no longer compares the deadline, which the Durable Object derives rather than trusts, so retrying the same stop maps to the same receipt instead of reporting a spurious Stop operation conflicts.

This also fixes a second defect found while tracing the first: withFields({ message }) overwrote the emitted message key (workers-tagged-logger emits Object.assign({}, log, this.getFields())), so the failure reason never reached the logs. It is now reason.

Verification

No manual tests were run, and I want to be explicit about why: reproducing the defect requires the Worker and the Durable Object to disagree on wall-clock time, which a single-machine local stack does not produce. The condition is positive skew (workerNow > doNow); a local stack shares one clock. The deployed E2E matrix is the real proof, and exercising it requires redeploying the cloud-agent-e2e-test Worker, which agents cannot do. So this change is verified at unit and wiring level only.

Automated checks on the pushed tree (services/cloud-agent-next):

• focused suites for the touched paths: 9 files, 794 tests passed;
• full package unit suite: 225 files, 6767 passed, 3 skipped;
• typecheck (including the wrapper package): exit 0;
• lint: 0 warnings, 0 errors over 558 files;
• format:check: exit 0.

Visual Changes

N/A

Reviewer Notes

• Intentional consequence: saturation means hop 2 may hold a shorter deadline than hop 1 persisted (min(D1, scNow + 10_000) <= D1). That shortens the downstream native-runtime retirement window (native-runtime-retirement.ts) rather than preserving it numerically. It does not renew the window on retry — an existing retirement receipt stays authoritative — and it stays compatible with receipt identity and recovery authority. Worth a look if you expect the deadline to be preserved end to end.
• Pre-existing assertions changed (disclosed): scoped-stop-maintenance.test.ts expected { cleanupDeadlineAt: 11_001 }, now: 1_000 to be rejected; it now saturates to 11_000. lifecycle.test.ts had a table row using cleanupDeadlineAt: Date.now() that only the removed upper-bound clause rejected — the fixture is now 1, which preserves the row's elapsed-case intent. Both changes are visible in the diff; no other existing test needed changing.
• Left alone deliberately: the wrapper's elapsed-only container-clock check (sandbox-control-handlers.ts) is the correct fail-closed direction and is out of scope. Extreme negative Worker skew (Worker clock far behind the acting clock) still rejects as elapsed, by design.
• Not changed, worth a follow-up: hop 2 still signals a rejected stop by throwing into progressSessionStop's silent catch, so a malformed or elapsed scoped stop remains invisible to the caller. This PR makes that path hard to reach, but does not make it observable.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Verified the per-hop Stop cleanup deadline change: the removed cross-clock upper bound is replaced by saturation to now + SANDBOX_CONTROL_CLEANUP_TIMEOUT_MS at both the Durable Object (admitSessionStop) and SandboxControl (parseScopedStopMaintenance), while an already-elapsed deadline still fails closed. Removing cleanupDeadlineAt from sameRequest keeps retries idempotent against the derived deadline, and the withFields({ reason }) rename avoids overwriting the emitted log message. The new and adjusted tests are deterministic (fake timers) and exercise read-side and write-side paths consistently.

Files Reviewed (8 files)

• services/cloud-agent-next/src/router.test.ts
• services/cloud-agent-next/src/router/handlers/session-management.ts
• services/cloud-agent-next/src/sandbox-control/lifecycle.test.ts
• services/cloud-agent-next/src/sandbox-control/scoped-stop-maintenance.test.ts
• services/cloud-agent-next/src/sandbox-control/scoped-stop-maintenance.ts
• services/cloud-agent-next/src/sandbox-session/session-message-queue.test.ts
• services/cloud-agent-next/src/sandbox-session/session-stop.test.ts
• services/cloud-agent-next/src/sandbox-session/session-stop.ts

---

_{Reviewed by deepseek-v4.1-flash · Input: 0 · Output: 0 · Cached: 0}

_{Review guidance: REVIEW.md from base branch main}