A waiter that times out while its lease is being written gets a timeout, and the lease is kept #402

Activity

1. V3RON

   added

   bug:newReported. Nobody has looked yet.Reported. Nobody has looked yet.

   on Oct 6, 2026
2. V3RON

   added

   bug:triageAn agent may reproduce it and write the triage report.An agent may reproduce it and write the triage report.

   and removed

   bug:newReported. Nobody has looked yet.Reported. Nobody has looked yet.

   on Oct 16, 2026
3. V3RON

   self-assigned this

   on Oct 16, 2026
4. V3RON commented on Oct 16, 2026

   

   V3RON

   on Oct 16, 2026

   ContributorAuthor

   More actions

   Reproduction

   Confirmed on origin/main (1b5537da). On bug/402-repro (0d9ee5e0),
   lease-acquisition-coordinator.test.ts: "delivers the grant to a queued waiter
   whose queue timeout falls due while its lease is being written".

   pnpm exec vitest run --project unit src/leasing/lease-acquisition-coordinator.test.ts \
     -t "delivers the grant to a queued waiter"
   -   "callerError": undefined,
   +   "callerError": "QueueTimeoutError",
   -   "outcome": "fulfilled",
   +   "outcome": "rejected",
   

   The body is right that a repeat under the same key gets that lease back. Wider damage:
   that lease belongs to a caller told it timed out, and blocks its next one.

   retry=RequesterAlreadyLeasedError records=[["holder","granted"],["waiter","granted"]]
   

   Root cause

   Defect. lease-acquisition-coordinator.ts:874 grants a ready device without
   marking the waiter processing, so it is still queued while #grant awaits the
   write (:915). WaitQueue#armTimeout (wait-queue.ts:377) spares only a waiter
   no longer queued, so the timer rejects this one mid-write. The grant is dropped:
   queue.resolve (:931) returns false, unread. Other paths mark first (:722,
   :887).

   Simplest fix

   Mark processing before the write, and re-queue a failed write as #grantPhysical
   does (:762-779) — four lines in #decide:

   if (!this.options.queue.markProcessing(waiter)) return undefined;
   try {
     await this.#grant(waiter, plan.device, plan.kind);
   } catch (error: unknown) {
     this.#logFailure("granting a ready device failed", waiter, plan.device, "grant", error);
     this.#defer(waiter);
   }

   A waiter timed out mid-attempt keeps its lease and sees the grant — the queue's own
   rule for that state (wait-queue.ts:339), not new policy. src/leasing green with
   it: 590 passed.

   Alternatives rejected

   • End the lease the write made: a lease ends only by release or TTL, and the device is
     reclaimed after a grant was promised.
   • Release on a false from queue.resolve: the caller still times out over a device it
     could have used.
   • Cancel this timer before the write: two places arm a deadline wait-queue.ts:332 says
     is armed once.

   Risk

   • waitingDemand (:628) now shows this waiter in flight during the write.
   • markProcessing without the catch wedges the waiter — pending, no timer,
     not-cancellable; the catch avoids the A lease request whose grant commit fails is left open forever, with no timer and no device work #647 shape.
   • No #wakeQueue after #defer, or a failing grant spins.

   Side findings

   • A lease request whose grant commit fails is left open forever, with no timer and no device work #647 — a lease request whose grant commit fails stays open forever.

   Written by an agent.
5. V3RON commented on Oct 16, 2026

   

   V3RON

   on Oct 16, 2026

   ContributorAuthor

   More actions

   Handoff

   Done — Reproduced on origin/main (1b5537da) as a failing unit test on
   bug/402-repro (0d9ee5e0, one file, no PR): "delivers the grant to a queued waiter
   whose queue timeout falls due while its lease is being written". Fails on a named
   assertion; pnpm exec vitest run --project unit src/leasing gives 1 failed, 589
   passed. Report posted above.

   Not done — the fix, and turning the repro into the closing PR's regression test
   (rule 9).

   Findings — the outcome is not an open decision: wait-queue.ts:339 says a timeout
   firing mid-attempt must not reject, and three paths already mark processing before one
   starts. Only grant-ready does not. The proposed fix's catch is load-bearing — with
   markProcessing alone, a createLease that throws leaves the waiter pending, untimered
   and not-cancellable.

   Blocked on — nothing. Maintainer decides bug:ready.

   Written by an agent.
6. V3RON

   removed their assignment

   on Oct 16, 2026
7. V3RON

   added

   bug:readyAn agent may fix it.An agent may fix it.

   and removed

   bug:triageAn agent may reproduce it and write the triage report.An agent may reproduce it and write the triage report.

   on Oct 16, 2026
8. V3RON

   self-assigned this

   on Oct 17, 2026
9. V3RON

   closed this as completedin #650on Oct 17, 2026