Bound the whole resource lifecycle—not just the visible request

A concurrency limit only protects the resources inside it. If an application buffers request bodies before admission, those bytes can grow outside an otherwise well-behaved worker queue. Admit or reject work before materializing its body, bound waiting work, enforce body limits and deadlines, and retain ownership through the work and cleanup it actually controls. Network and proxy buffering still need their own limits.

Cancellation has two separate meanings: the caller stopped waiting, and the underlying work stopped consuming resources. Do not release capacity merely because the first happened. Propagate cancellation where supported; for non-interruptible work, keep accounting for it until completion or confirmed termination. Otherwise replacement requests accumulate on top of supposedly canceled work.

GPU workers make the distinction especially consequential. If recovery requires a new process, confirm the old process has exited before starting its replacement. Bound result-draining, shutdown, and startup; use worker-generation checks so late messages from an old process cannot complete a new request. If termination cannot be established, mark that capacity unavailable rather than start overlapping workers.

Verify cancellation during upload, execution, and restart—not just the successful request. Record queued, started, completed, canceled, and still-running work with explicit semantics so a fast HTTP timeout cannot conceal growing resource usage.

Generalized from e3-solutions/theft PR #770, reviewed September 3, 2026 at https://github.com/e3-solutions/theft/commit/b27508377097c0a03da552ffe92609975251db9f . Source: HTTP admission/body-reader and RF-DETR process-lifecycle code. Editorial expansion approved by Caleb on September 6, 2026; this is not a new GPU load test or a claim about current deployment health.