billowy-hairdresser-80384
04/05/2026, 6:38 AMtall-airline-16756
04/05/2026, 6:38 AMtall-airline-16756
04/05/2026, 6:39 AMasyncio.CancelledError handling is correct and if you should re-raise. You're handling the right scenario.
What you're doing now is correct:
• Log the cancellation for visibility.
• Re-raise asyncio.CancelledError instead of suppressing it or calling your _shutdown() there.
Why: a CancelledError means the framework is already tearing down the task. Suppressing it or calling _shutdown() from inside the cancelled task can cause double-cleanup or interfere with the framework’s lifecycle. Logging + re-raising lets the framework complete shutdown and cleanup reliably.
One small suggestion for clarity: catch only asyncio.CancelledError (not a broad exception) and keep the handler minimal, e.g.:
except asyncio.CancelledError:
logger.warning("end_call task cancelled — re-raising.")
raise
That keeps intent explicit and avoids accidentally catching other exceptions.
Sources: Workflows | LiveKit Documentation | Function tool definition | LiveKit Documentation | Turns overview | LiveKit Documentation | Python Agents: Handling exceptions in your entrypoint | LiveKit, with interactive elementsbillowy-hairdresser-80384
04/05/2026, 6:40 AMtall-airline-16756
04/05/2026, 6:40 AMasyncio.CancelledError happens, the framework is already shutting things down.
• Do not call your own _shutdown() from inside that handler.
• Log it if you want, then re-raise so the framework can finish cleanup.
Do you want a one-line code example showing exactly where to re-raise?
, with interactive elements