Asyncio remote debugging tools can error while attaching

[johnslavik]

Bug report

Bug description:

Tachyon profiler collections always have some error rate.

My intuition is that the same applies to the asyncio debugging tools -- they can try to attach in a wrong moment.

I've played with

cpython/Lib/profiling/sampling/sample.py

Lines 120 to 123 in 837166f

	except (RuntimeError, UnicodeDecodeError, MemoryError, OSError):
	collector.collect_failed_sample()
	errors += 1
	except Exception as e:

and the errors look very similar.

They are especially visible when running the asyncio debugging tools on asyncio programs that use thread delegation:

Screen.Recording.2026-02-16.at.16.22.21.mov

(Code used)

import asyncio
import os

async def task_inner():
    with open("/dev/urandom", "rb") as urandom:
        feed = await asyncio.to_thread(urandom.read, 128)
        print(feed[:16].hex(), "\r", end="")

async def task():
    async with asyncio.TaskGroup() as tg:
        tg.create_task(task_inner())

async def main():
    while True:
        await task()

if __name__ == "__main__":
    print(f"PID: {os.getpid()}")
    asyncio.run(main())

Regular users won't use watch, so these expected errors could confuse them. I think we should handle this somehow.

My idea is to simply write a retry loop for asyncio debugging tools attaching and maybe let the user control the number of retries to attempt through a CLI flag.

Another idea could be to hint the user of the asyncio debug tools that errors can happen and that it is not a bug, and they could retry themselves.

cc @pablogsal

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux, macOS

Linked PRs

• gh-144881: Add retry logic to asyncio debugging tools #148530

[pablogsal]

My idea is to simply write a retry loop for asyncio debugging tools attaching and maybe let the user control the number of retries to attempt through a CLI flag.

This looks very reasonable 👍

Another idea could be to hint the user of the asyncio debug tools that errors can happen and that it is not a bug, and they could retry themselves.

Very reasonable as well :)

[johnslavik]

I'll merge these two ideas together.

I think a retry option is important as a default also for scenarios where error reports are automated and somebody gets an output from -m asyncio pstree included in it. Seems like a strong use case, auto-retry would be very helpful.