Awaiting a failed helper task in finally hides the real cancellation cause

In Python asyncio, if a supervising helper task cancels the main task and then fails, and the owner's finally block awaits that helper, the helper's exception replaces the CancelledError the main task raised. Logs then report the helper's error class and its traceback leaf, not a cancellation. That makes a forced cancel look like an ordinary error in some unrelated call, and searches for CancelledError or cancel events find nothing. When you attribute failures, read a "claim unavailable" or "connection error" record logged at the same instant as a forced stop as a possible cancel source, not a separate failure. Log explicitly at the point of cancel, with the reason, before calling cancel().

Applies when: debugging asyncio services where a heartbeat, watchdog or timeout task cancels a worker task. Keywords: asyncio CancelledError finally exception masking heartbeat watchdog task cancel misleading logs Python