fix(seller): re-acquire a slot permit for jobs resumed after restart

[orveth]

Closes #251 (#223 P4).

The defect

The restart path re-drove every non-terminal job with no permit:

runner.execute_job(&job_id, None).await;   // the `None` is the permit

Reservations cannot survive a process by construction — ParkedSlot.reserved_at is a monotonic Instant and the parked map is in-memory — so every permit is free when resumed jobs start and take_for_execution has nothing to hand them. A node returning with K non-terminal jobs ran up to slots + K concurrent executions against a ceiling of slots, and could claim slots further offers on top because the gate reported full capacity. Invisible at slots = 1; the excess scales with K exactly as we raise slot counts.

The fix

Each resumed job waits for a real permit before executing, via SlotGate::acquire_for_resume. The wait happens inside the spawned task, never on the loop: a fan-out that awaited capacity at boot would deafen the node that just restarted (#223).

Decision 1 — what happens when K > slots

Queue the excess. Tokio's semaphore hands permits to waiters in order, so resumed jobs run in waves as earlier ones finish, and all K eventually run.

Rejected refuse to resume beyond capacity: it quietly abandons awarded work, and under award-is-payment those are sats the buyer has already committed. Rejected resume serially: it throws away the capacity an operator configured.

Consequence worth stating: while the backlog drains the node stops claiming new offers (try_reserve finds no free permit ⇒ SlotsBusy). That is the intended back-pressure and it is precisely why the bound is slots rather than slots + K — a restarted node with a backlog should be invisible to the market until it catches up.

Not silent: the resume log carries the count with its denominator (N job(s) to re-drive, bounded to M execution slot(s)), because an operator seeing only a count cannot tell whether waves are happening.

Decision 2 — the lapse clock for a re-acquired permit

There isn't one, and that is the answer rather than a gap in it.

The permit is never parked and no reserved_at is seeded. reserved_at bounds a claim waiting to be awarded; a resumed job is already awarded and executing, so seeding a fresh Instant::now() would start a timer over a state the sweep was never meant to measure — the "ceiling without a floor" the issue warns about. sweep_lapsed iterates only the parked map, so it cannot reclaim a resumed job's permit. Release is the existing RAII pairing: the execution future returning, unwind included.

Pinned by its own test (a_resumed_permit_is_not_parked_so_the_lapse_sweep_cannot_reclaim_it) with lapse_after = 0ms, so the sweep would fire on anything parked.

Red leg

Pass None instead of acquiring — the pre-fix path exactly — and a_restart_resumes_more_jobs_than_slots_without_exceeding_capacity fails:

assertion `left == right` failed: concurrent resumed executions must never exceed the configured slots
  left: 4
 right: 2

Four resumed jobs, two slots, all four concurrent. That is #251. 13 other gate tests stayed green, and the lapse-clock test also stayed green under this revert (it calls acquire_for_resume directly rather than the fan-out) — so the two tests are independent, not one property asserted twice.

What the test covers, and the one thing it does not

The fan-out is generic over its execution step so the part carrying the bound is reachable without a relay, an agent, or a store. The stub is sound rather than a shortcut: the bound is a property of the fan-out, not of what a job does, and stubbing is what makes peak concurrency observable at all.

⚠ The gap, stated rather than discovered in review: the test does not prove the production loop passes execute_job as its step. That is one call site, checked by the compiler and by reading. If you want that leg too it needs a fixture that instruments a real execute_job, and I'd rather scope it separately than claim it here.

The overlap is real, not incidental — the stub yields across an await, so a bound that held only because nothing ever ran concurrently would not pass. Drain is a bounded poll, not a fixed sleep, so a slow box cannot flake it.

Counts

cargo test -p mobee-core --features wallet --locked: 661 → 663 = +2, 0 failed, 3 ignored.

⚠ cargo test -p mobee-core --locked (CI job 1) stays at 196 — unchanged, and correctly so: seller_node is #[cfg(feature = "wallet")] with default = [], so both new tests live where the code lives and are not in the default denominator. The wallet build is the only one that exercises them.

🤖 Generated with Claude Code

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
mobee	Ready	Preview	Jul 30, 2026 2:33pm