Asyncio does not handle nested KeyboardInterrupt correctly

[user202729]

Bug report

Bug description:

Consider this code

import sys
import logging
import asyncio
import signal
from time import*

logger = logging.getLogger(__name__)

logging.basicConfig(level=logging.INFO)

async def f():
    if 1:
        main_task = asyncio.current_task()
        def on_sigint() -> None:
            logger.error("Received SIGINT")
            main_task.cancel(KeyboardInterrupt)
        asyncio.get_running_loop().add_signal_handler(signal.SIGINT, on_sigint)
    try:
        while True:
            await asyncio.sleep(0.1)
            print("*")
    except asyncio.CancelledError as e:
        print(e)
        try:
            while True:
                await asyncio.sleep(0.1)
                print("#")
        except asyncio.CancelledError:
            try:
                while True:
                    await asyncio.sleep(0.1)
                    print("!")
            except asyncio.CancelledError:
                while True:
                    await asyncio.sleep(0.1)
                    print("@")

asyncio.run(f())

Intention: each time I press Ctrl-C, it repeatedly print *, #, !, @ respectively.

As is, it does do that correctly.

However, if I don't manually add the SIGINT signal handler, it will print *, {first Ctrl-C} #, {second Ctrl-C} !, {third Ctrl-C} then forcefully stop.

I don't think this behavior is desirable. Or at least it probably shouldn't log a scary error Task was destroyed but it is pending!?

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Linked PRs

• gh-146194: Fix nested KeyboardInterrupt handling in asyncio #146203

[okiemute04]

@user202729, this is a good issue to work on. The problem seems to be that asyncio's default signal handler doesn't properly handle nested cancellation scenarios. When the user adds a custom handler, it works correctly because they're manually managing the cancellation propagation. The default handler needs to be improved to handle nested cancellations properly. Let me investigate the signal handling in Lib/asyncio/unix_events.py, the cancellation propagation in Lib/asyncio/runners.py and Lib/asyncio/tasks.py, and how KeyboardInterrupt is currently being propagated through multiple cancellation layers. I do think a better plan is to ensure that when a nested cancellation occurs, the KeyboardInterrupt is properly passed through each layer, rather than causing a Task was destroyed but it is pending! error.