fix(leasing): a ready grant marks its waiter in flight before the write (#402) by V3RON · Pull Request #650 · callstackincubator/simlock

V3RON · 2026-10-17T06:33:02Z

Closes #402

Status

Implement: done (592/592 leasing green) Review: round 1 passed (spec, code, claims: F0) Hardware: n/a Gate: running
Next: gate result

A waiter whose queue timeout falls due while its lease is being written gets the grant, not a timeout — #decide marks the ready grant processing before the write, so the queue's mid-attempt rule spares it; the triage test lands in this PR and passes
A ready grant whose registry commit throws defers the waiter with one warn (step=grant) and grants it on the next wake — the catch mirrors #grantPhysical; the pin fails on its log assertion without it
A ready grant the queue will not put in flight writes no lease — the markProcessing refusal is checked before #grant; the pin fails on its device/lease assertions without it

The only caller-visible additions: a failed ready grant now logs one warn line and the
waiter stays open for the next wake instead of wedging, and waitingDemand reports the
waiter in flight during the write — the triage report lists both as intended.

Assumptions

Assumption: a refused markProcessing on the ready path ends the drive silently (return undefined) rather than deferring — the queue refused because the waiter is at its deadline and already rejected; deferring would re-queue a dead waiter. Same handling as the plan path at the other markProcessing call.

Review

Spec review: 0 blocking, 0 fixed, 0 notes. Code review: 0 blocking, 0 fixed, 0 notes. Claims review: 0 blocking, 0 fixed, 0 notes.
Rounds: 1. Tokens: n/a.

Kind full, so all three reviews ran; the code reviewer with lens: both in its own worktree of 3a1d0cee. Inputs came from .agents/scripts/review-inputs.sh 650 (rules, ADRs and briefs from main).

How the reviews were spawned: this session sits at subagent depth and the harness refused nested spawns, as on #643, #644 and #646. Each reviewer ran as a fresh detached claude -p session — the body of .claude/agents/<reviewer>.md as its system prompt, its model from that file's frontmatter — reading only the inputs directory and its own worktree of the reviewed commit, with no PR body, commit messages or another reviewer's output. Nothing was reviewed by the agent that wrote the code.

Written by an agent.

…ts lease is being written gets a timeout while its lease is kept

…402)

…r a failed one The ready path granted without marking the waiter processing, so a queue timeout falling due while the lease was written rejected the caller over a lease that was being stored. Mark processing before the write, matching every other attempt path, and re-queue a grant whose commit throws, as the physical grant does.

…658) Closes #647 ### Status Implement: done (596/596 leasing, 2348/2348 changed) Review: round 1 + fix check passed (spec, code, claims: F0) Hardware: n/a Gate: running Next: gate result - [x] A waiter whose grant of the booted or provisioned device fails to store is deferred with one `warn` (`step=grant`) and granted on the next wake — the triage tests from `bug/647-repro` land in this PR and pass; deleting the `catch` turns both red on the grant-step `warn` assertion, and a `catch` without the `#defer` turns both red on `queueDepth` - [x] A failed handoff grant still releases the device claim and the capacity reservation — the releases stay in the `finally`; deleting them turns 40 leasing tests red, including the two triage tests ## Assumptions - Assumption: the `warn` message names the plan kind ("granting a provisioned device failed" / "granting a booted device failed") — matches the wording of the sibling grant-failure lines; no test or doc pins message text. ## Review Spec review: 0 blocking, 0 fixed, 0 notes. Code review: 0 blocking, 0 fixed, 0 notes. Claims review: 0 blocking, 0 fixed, 0 notes. Rounds: 1. Tokens: n/a. How the reviews were spawned: this session sits at subagent depth and the harness refused nested spawns, as on #643, #644, #646 and #650. Each reviewer ran as a fresh detached `claude -p` session — the body of `.claude/agents/<reviewer>.md` as its system prompt, its model from that file's frontmatter — reading only the inputs directory from `.agents/scripts/review-inputs.sh` and its own worktree of the reviewed commit, with no PR body, commit messages or another reviewer's output; each read `.agents/briefs/calibration.md` first. Round 1 reviewed `90d98d35`; a format-hook rewrap of one test line forced a history rewrite, so a fix check (code and claims, `lens: both`) reviewed `90780cc9` and confirmed the delta formatting-only (F0 both). Nothing was reviewed by the agent that wrote the code. *Written by an agent.*

… refused (#661) Closes #389 ### Status Implement: done (green; probe red on both claims) Review: round 1, 1 text fixed unreviewed Hardware: n/a Gate: running Next: gate result ## Done when - [x] The warm pool leaves a device of a platform whose driver was refused out of its shutdown and boot choice — the triage repro (carried unchanged from `bug/389-repro`) is the regression test - [x] The next least recently used device is shut down instead and the pool comes back under budget — same repro, its named assertions - [x] The refused platform's device stays counted in capacity, so the pool sees no free slot and does not over-subscribe — the view's capacity totals stay unfiltered; a probe filtering them reddens the repro and the table test ## Assumptions - Assumption: whether a refused platform's device stays warm-listed to the reaper through `targeted()` — left as today (still listed): the reaper's own abort on such a device is #659, and changing the list here would decide that reaper behaviour without its spec. ## Review Spec review: 0 blocking, 0 fixed, 0 notes. Code review: 0 blocking, 0 fixed, 0 notes. Claims review: 1 blocking, 1 fixed, 0 notes. Rounds: 1. Tokens: n/a. Fixed unreviewed: - claims: src/core/create-core.test.ts:604 the repro's `why:` said the pause is one tick plus a millisecond; 31_000 ms is one tick plus a second (comment only, assertions unchanged) Kind `full`, so all three reviews ran; the code reviewer with `lens: both` in its own worktree of `49658360`. Inputs came from `.agents/scripts/review-inputs.sh 661` (rules, ADRs and briefs from `main`). How the reviews were spawned: this session sits at subagent depth and the harness refused nested spawns, as on #643, #644, #646, #649 and #650. Each reviewer ran as a fresh detached `claude -p` session — the body of `.claude/agents/<reviewer>.md` as its system prompt, its model from that file's frontmatter — reading only the inputs directory and its own worktree of the reviewed commit, with no PR body, commit messages or another reviewer's output. Nothing was reviewed by the agent that wrote the code. *Written by an agent.*

…664) Closes #659 ### Status Implement: done (14/14 reaper file, 1222/1222 `src/core`, 4379/4379 `pnpm test:changed`; probes 2/2) Review: round 1, 0 blocking, 0 fixed unreviewed, 0 notes Hardware: n/a Gate: running Next: merged or parked with the line it printed ## Done when - [x] One action that throws inside the reaper's loop is contained, logged, and the run continues, so every proposal after a device whose platform has no driver is still executed, for both the idle-shutdown and the idle-destroy verb — the carried repro (`src/core/reaper.test.ts`, both verbs in one run) - [x] A run-level failure (a rule or the registry view that throws) still rejects the run — "A cleanup run that throws logs at error." and "a cleanup run that throws is logged once, however many triggers joined it" - [x] The fix adds no third `hasDriver` filter and duplicates no skip predicate — the catch is at `execute`; nothing was added to `#view()` Probes run on the final head, each reverted after: - Revert (the bare `await` restored): the repro reds on its own named assertion — `promise rejected "NoDriverError: No driver registered for platform: android" … at CleanupReaper.#runOnce`, and the log test reds on its resolve assertion. - Over-catch (the catch widened around the whole pass): both run-level tests above red on their log assertions, so they are live and the catch sits at `execute`, not around the pass. New path and its test (strict area): the `catch` adds one path, the `cleanup action failed` line, proven by "logs a cleanup action that throws at error, naming the action, rule and target, and still resolves the run". The repro covers the continue side for both verbs. ## Assumptions - Assumption: exit status of `simlock cleanup` with a failed action — it now exits 0 with the failure only in an error log; this follows from the fault isolation the triage chose and no doc says otherwise. `docs/CLI.md`'s `cleanup` section and its exit-code table name no failure for a command whose run completes, `NO_DRIVER` (12) stays true of the commands that still surface it, and no e2e or client test pins a throwing `cleanup.run`. For #660: `NukeService.#runNuke` has the same loop with the same missing catch; the shape here (catch at `execute`, log, continue) factors to it, but its spec decides its own fix and this PR does not touch it. ## Review Spec review: 0 blocking, 0 fixed, 0 notes. Code review: 0 blocking, 0 fixed, 0 notes. Claims review: 0 blocking, 0 fixed, 0 notes. Rounds: 1. Tokens: n/a. Nothing was rejected, so nothing is listed. Round 1 confirmed no *src* finding, so round 2 and the fix check did not run (rule 14). Kind `full`, so all three reviews ran; the code reviewer with `lens: both` in its own worktree of `cffd92ee`. Inputs came from `.agents/scripts/review-inputs.sh 664` (rules, ADRs and briefs from `main`). How the reviews were spawned: this session sits at subagent depth and the harness refused nested spawns, as on #643, #644, #646, #649, #650 and #661. Each reviewer ran as a fresh detached `claude -p` session — the body of `.claude/agents/<reviewer>.md` as its system prompt, its model from that file's frontmatter — reading only the inputs directory and its own worktree of the reviewed commit, with no PR body, commit messages or another reviewer's output; each read `.agents/briefs/calibration.md` first. Nothing was reviewed by the agent that wrote the code. *Written by an agent.*

…668) Closes #660 ### Status Implement: done (8/8 in `nuke-service.test.ts`; `pnpm test:changed` 4387 passed) Review: round 1, 0 open Hardware: n/a Gate: running Next: gate result ## What is this? `simlock nuke` stopped at the first device whose platform has no driver: `NoDriverError` escaped the reset loop, every device after it stayed booted, and the command reported failure. One device that cannot be reset is now logged and the reset goes on. ## How does it work? `NukeService.#runNuke` catches around the per-device `#resetDevice` call only — the inline shape #664 landed in the cleanup reaper, no shared helper. A maintenance or release-all failure still rejects the run, and the `finally` still reopens admission. `NukeService` had no logger; it takes an optional one now, wired where `create-core.ts` builds it, and the device it could not reset is logged at error with its id, platform and error. ## Done when - [x] The reset does not abort on a device whose platform has no driver and still resets every device after it — the triage reproduction, carried unchanged from `bug/660-repro`, is green: both driverless records are passed over and the healthy device after each ends `deleted`, across both verbs. Reverting the catch reddens it on `NoDriverError`. - [x] The new branch has its own path test, as a strict area needs — "logs a device it cannot reset at error, naming the device, platform and error". Deleting the log line reddens that test alone. - [x] A maintenance or release-all throw still rejects the run — "reopens admission even when reset work fails" is untouched and live: widening the catch over the whole loop reddens it. `src/core/AGENTS.md`'s Nuke item states the isolation and stays within its 150-line budget. No end-user doc claimed `nuke` fails when one device cannot be reached, so none changed; no event changed. ## Assumptions - Assumption: exit status of `simlock nuke` with a device it could not reach — it now exits 0 with the failure only in an error log; this follows from the fault isolation the triage chose and no doc says otherwise. `docs/CLI.md`'s nuke section and exit-code table checked: neither states that nuke fails when one device cannot be reached. ## Review Spec review: 0 blocking, 0 fixed, 1 note. Code review: 0 blocking, 0 fixed, 0 notes. Claims review: 0 blocking, 0 fixed, 0 notes. Rounds: 1. Tokens: n/a. Kind `full`, so all three reviews ran; the code reviewer with `lens: both` in its own worktree of `d54b86b5`. Inputs came from `.agents/scripts/review-inputs.sh 668` (rules, ADRs and briefs from `main`), and the reviewers saw no PR body, no commit messages and none another reviewer's output. How the reviews were spawned: this session sits at subagent depth and the harness refused nested spawns, as on #643, #644, #646, #649, #650 and #661. The `reviewer` agent ran instead as a fresh detached `claude -p` session on `bug/660` — its definition from `.claude/agents/reviewer.md`, its model from that file's frontmatter — which spawned the three reviewers itself as its own fresh sub-agents, each reading only the inputs directory and its own worktree of the reviewed commit. Nothing was reviewed by the agent that wrote the code. *Written by an agent.*

… a stopping gateway (#642) (#667) Closes #642 ### Status Implement: done (repro red 8e565b6 -> green cf17fb2; fix commit 759ebe2) Review: round 2 passed (spec/code/claims F0) Hardware: n/a Gate: not run Next: gate ## Done when - [x] The lane's /v1/workers response helpers survive the gateway's listener stopping between interception and fetch — the carried repro (`workers-gateway-stops-mid-fetch.spec.ts`, adapted to call the real extracted helpers) is red at 8e565b6 with the lane's `route.fetch: connect ECONNREFUSED` signature and green from cf17fb2; the helpers drop that re-read with `route.abort()` - [x] A non-connect error from the re-read still fails the test (the narrow catch) — pinned: a rejection the regex does not match propagates out of the handler with no abort; probes: broadening the catch reddens the non-connect case, dropping it reddens the connect and repro cases; narrowing the regex to `ECONNREFUSED` reddens the ECONNRESET / socket-hang-up cases - [x] `workers.spec.ts` keeps passing with the helpers extracted, unchanged behavior — the two helpers moved to `workers-answers.ts` verbatim but for the `fetchOrDrop` guard; lane run green ## Assumptions - Assumption: the connect-level classes are `ECONNREFUSED`, `ECONNRESET` and `socket hang up` — the three the triage census observed (refused connect and destroyed mid-request); any other error still rethrows. ## Review Spec review: 0 blocking, 0 fixed, 0 notes. Code review: 2 blocking, 2 fixed, 0 notes. Claims review: 0 blocking, 0 fixed, 1 note. Rounds: 2. Tokens: n/a. Kind `tests-only`, so all three reviews ran; the code reviewer with `lens: tests`. Inputs from `.agents/scripts/review-inputs.sh 667` (rules, ADRs and briefs from `main`). Round 1 reviewed `cf17fb26`; round 2 reviewed the fix `759ebe28` (code + claims, F0 both). How the reviews were spawned: this session sits at subagent depth and the harness refused nested spawns, as on #643, #644, #646, #649, #650 and #661. Each reviewer ran as a fresh detached `claude -p` session — the body of `.claude/agents/<reviewer>.md` as its system prompt, its model from that file's frontmatter — reading only the inputs directory and its own worktree of the reviewed commit, with no PR body, commit messages or another reviewer's output; each read `.agents/briefs/calibration.md` first. Nothing was reviewed by the agent that wrote the code. *Written by an agent.*

…#665) (#669) Closes #665 ### Status Implement: done (600/600 leasing, 2354/2354 changed; both probes red) Review: round 1 passed (spec, code, claims: F0) Hardware: n/a Gate: running Next: gate result - [x] `#decide` plans no device work for a waiter `markProcessing` has just rejected — the guard at `src/leasing/lease-acquisition-coordinator.ts:904` mirrors the ready-grant branch the report points at; the new eviction test drives a real `timeoutMs` deadline falling due inside the eviction and fails on `createdModels` gaining `"iPhone 16"` without the guard - [x] A refused plan gives back what it holds — `releasePlanResources`; deleting only that release turns the eviction test red on `reservedRunning: 1` and all three table cases red on `NoCapacityError` for the next request - [x] The refusal leaves nothing queued behind a plan nobody performs — each table case asserts `outcome: "pending"` with `queueDepth: 0` Only the refused plan's own work disappears. The caller's answer is unchanged: the queue's own expiry had already settled it with `QueueTimeoutError`. ## Assumptions - Assumption: a refused `markProcessing` on the operation branch ends the drive silently, as the ready-grant branch already does — the queue refused because the waiter is at its deadline and already rejected; deferring would re-queue a dead waiter. ## Review Spec review: 0 blocking, 0 fixed, 0 notes. Code review: 0 blocking, 0 fixed, 0 notes. Claims review: 0 blocking, 0 fixed, 1 note. Rounds: 1. Tokens: n/a. Fixed unreviewed (text, commit `a3d448ae`: comments only, no assertion changed): - claims: src/leasing/lease-acquisition-coordinator.test.ts:1549 the `why:` named a capacity reservation for the two `evict-*` cases, which hold a claim only; the guard's own comment said the same and was fixed with it Kind `full`, so all three reviews ran; the code reviewer with `lens: both` in its own worktree of `3cb8cada`. Inputs came from `.agents/scripts/review-inputs.sh 669` (rules, ADRs and briefs from `main`). How the reviews were spawned: this session sits at subagent depth and the harness refused nested spawns, as on #643, #644, #646, #649 and #650. Each reviewer ran as a fresh detached session reading only the inputs directory and its own worktree of the reviewed commit, with no PR body, commit messages or another reviewer's output, and read `.agents/briefs/calibration.md` first. Two deviations, both disclosed: the `claude` CLI reported its monthly spend limit exhausted until 2026-10-18 15:00, so the children ran as detached `opencode run` sessions rather than detached `claude -p` ones; the pinned reviewer models (`opus`, `sonnet`) are not reachable there, so each ran on the one model that was. Nothing was reviewed by the agent that wrote the code. *Written by an agent.*

V3RON added 3 commits October 17, 2026 07:47

test: reproduce #402 — a waiter whose queue timeout falls due while i…

5fdcb88

…ts lease is being written gets a timeout while its lease is kept

test: pin the ready grant's in-flight mark and its failed-write path (#…

e62808f

…402)

V3RON marked this pull request as ready for review October 17, 2026 06:38

V3RON merged commit 58bba81 into main Oct 17, 2026
52 of 53 checks passed

V3RON deleted the bug/402 branch October 17, 2026 06:42

V3RON mentioned this pull request Oct 17, 2026

fix(leasing): a handoff grant whose commit throws defers its waiter #658

Merged

2 tasks done

V3RON mentioned this pull request Oct 17, 2026

fix(core): the warm pool skips devices of a platform whose driver was refused #661

Merged

3 tasks done

V3RON mentioned this pull request Oct 17, 2026

fix(core): the cleanup reaper finishes its run when one action fails #664

Merged

3 tasks done

This was referenced Oct 17, 2026

fix(console): the workers-list lane helpers drop a re-read refused by a stopping gateway (#642) #667

Merged

fix(core): the operator reset finishes when one device has no driver #668

Merged

V3RON mentioned this pull request Oct 17, 2026

fix(leasing): no device work for a waiter the queue has just rejected (#665) #669

Merged

3 tasks done

Navigation Menu

Repository navigation

fix(leasing): a ready grant marks its waiter in flight before the write (#402) - #650

fix(leasing): a ready grant marks its waiter in flight before the write (#402)#650
V3RON merged 3 commits into
mainfrom
bug/402

V3RON commented Oct 17, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

V3RON commented Oct 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Status

Assumptions

Review

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

V3RON commented Oct 17, 2026 •

edited

Loading