[jrzmurray]

What this changes

V2 interrupt now cancels the registered provider drain, reports its actual interruption result, and keeps later work ordered behind terminal publication. The bounded drain admission and per-session deletion fence prevent queued work or an in-flight turn from being stranded or writing into a deleted session. This change covers K-V2-DRAIN-CANCEL and K-SESSION-DELETE-FENCE.

Issue

Closes #

Verification

• cargo fmt --check — passed
• cargo clippy --workspace -- -D warnings — passed
• v2_admission integration target — 22 passed
• drain and deletion race tests — 15 passed
• coordinator tests — 5 passed
• uv run --with jsonschema bash ./scripts/check-guards.sh — passed
• ./scripts/check-matrix.sh — passed
• cargo test --workspace — blocked on this macOS host by seven Linux cgroup tests and one /proc RSS test
• cargo test -p ocserve-http — 57 passed, 1 unrelated symlink containment test failed on this host

Linux CI remains the full-workspace gate.

[alderpath]

Thanks — the core insight is right and the delete fence is the correct shape. I approved the workflows (fork runs had never executed) and pushed two commits onto your branch; tell me if you would rather have them as a separate PR.

What I changed, and the evidence

1. Admission was back on the async worker. check_v1_session_admission called session_exists (an open_reader + SELECT count(*)) inline on every v1 prompt — and it had replaced the run_blocking call prompt_async already had, so the PR was a net loss of offload. It is now async and routes the query through run_blocking. This is the F1 convoy class the repo already fixed once; five routes were affected.

2. The delete wait needed TWO bounds. Your cancel_drain waits on completion_rx.changed(); I bounded that, then wrote a test with a fabricated registry entry that never confirms, and it still hung for 90 s. Reason: cancel_drains_for_delete is a loop that re-cancels, so bounding only the inner call just pays the budget repeatedly. Both loops now share one deadline (OCSERVE_DRAIN_CANCEL_SECS, default 30 s) and record ocserve_v2_drain_cancel_timeout_total. The test is delete_returns_when_a_registered_drain_never_confirms_cancellation; its negative control (remove the outer deadline) hangs to the timeout.

3. Capacity detection was string matching. error.message == "too many concurrent prompts" — a wording change would silently drop into the 1 Hz retry branch while holding a drain slot. Now matched on status + name.

4. The scheduler awaited capacity in its serial loop. One slow drain stalled every other schedule, for every session. It now uses the non-blocking reservation and returns without marking the row, so the next pass retries.

5. unwrap_or(false) on the interrupt re-arm. A read error became "session gone" and the re-armed steer work was dropped silently. It propagates now.

On the MEMORY claim: I rewrote it as an explicit count bound with the real worst case, min(128 slots, 64 prompt locks) x history, because MAX_PROMPT_LOCKS is what actually caps concurrent turns.

One contract note, recorded not fixed: /api/session/{id}/interrupt is in both contracts — v1 says 204, v2 says 200 — and it is not in the v2-only table, so a v2-disabled server now answers 200 where its v1 contract says 204. No shipped v1 client calls it (1.19.5's v1 SDK uses /session/{id}/abort), so I logged it as D-V2-INTERRUPT-STATUS rather than splitting the handler. If you want the split, say so.

The 1,400-line inline test module stays: integration tests cannot see the #[cfg(test)] seams, so moving it would mean rewriting six race tests. Reviewing the seams is the better trade.