A running-slot reservation can leak when the warm pool claims a device between a failed boot and its destroy

[V3RON]

Found in the review of PR #394 by reading the code; not reproduced. main has the same code.

src/core/lease-acquisition-coordinator.ts:844-858: a failed boot-for-lease releases its boot claim (src/core/managed-device-lifecycle.ts:251) before destroy claims the device again in a later decision. If the warm pool's boot (src/core/warm-pool/converger.ts:189) claims the shut-down device in between, destroy returns undefined, no fence is taken, and the waiter's running-slot reservation is not released until the daemon restarts.

Written by an agent.

[V3RON]

Reproduction

Confirmed, a defect. It needs a running limit of 2 or more, or the warm pool cannot reserve its boot. Since #383 the coordinator is src/leasing/lease-acquisition-coordinator.ts, and the lifecycle releases the claim at src/core/managed-device-lifecycle.ts:248.

Branch bug/401-repro, test "releases the running slot reserved to boot a shut-down device for a waiter when the boot fails and another boot claims the device before it is destroyed". The test plays the warm pool: just before destroy it reserves a slot and claims the device, then gives both back.

pnpm exec vitest run --project unit src/leasing/lease-acquisition-coordinator.test.ts

AssertionError: expected { global: 1, ios: 1 } to deeply equal { global: +0, ios: +0 }

Root cause

src/leasing/lease-acquisition-coordinator.ts:834-836 treats destroy returning undefined like destroy throwing. A throw means the driver failed and the device may still run, so keeping the slot and fencing (848-850) is deliberate. undefined means the device is no longer the waiter's: another boot claim got in after the lifecycle released the waiter's. The fence is skipped because the device is claimed, and nothing else releases the waiter's reservation. The other owner holds its own slot, so this one is lost until restart.

Simplest fix

Release the reservation whenever destroy does not throw:

try {
  await this.options.lifecycle.destroy(device, "lease-engine", "boot");
} catch (destroyError: unknown) {
  // log as now
  destroyed = false;
}

Checked: the test and the coordinator and create-leasing files pass (234 tests).

Alternatives rejected

• Keep the boot claim through the failure and pass it to destroy: changes the release-on-failure contract bootWarm shares.
• Fence even when claimed: blocks a device the warm pool now owns, for good.
• Release from the warm pool: it does not own that reservation.

Risk

• undefined also covers a device deleted or leased meanwhile. Releasing is right there too, but no test covers it; check nothing relied on the fence.
• The failed device stays; the warm pool may boot it again, bounded by its retry backoff.

Written by an agent.