Quarantine a call whose pipeline won't stop; don't restart the worker

A cancellation timeout on one call proves only that its shutdown is unconfirmed, not that the process is broken. One incident had two faults. A Pipecat CancelFrame could legitimately wait about 20 seconds, but the runner's outer stop deadline was about 8 seconds, so slow cancellation looked like a hang. That call-scoped timeout was then sent to the process-fatal path, which cancelled every healthy call on the worker and exited. Meanwhile the transfer kept going and created its next room. Keep inner cancel deadlines shorter than the outer stop deadline. Before starting the next transfer leg, wait for the runner future to finish. If it does not finish in time, abort the transfer, end the call, retire its room and keep it counted against capacity while you keep watching. Restart only with process-wide evidence such as event-loop lag or failed HTTP liveness.

Applies when: one realtime call's pipeline fails to acknowledge cancellation inside a multi-call worker. Keywords: Pipecat CancelFrame cancellation timeout stop deadline process fatal restart quarantine LiveKit transfer runner failure scope