`create_task(name=...)` silently fails to set name with custom task_factory after gh-128308

[sergiosacj]

Bug report

Bug description:

During a rebuild of all packages in Debian unstable, the uvloop test suite failed due to a new behavior in asyncio.

This suite runs each test twice: once with uvloop implementation (which passes) and once with Python’s asyncio implementation (which fails).

Since

Commit: 38a99568763604ccec5d5027f0658100ad76876f
PR: https://github.com/python/cpython/pull/128768

asyncio.BaseEventLoop.create_task() no longer calls set_name(name). This breaks compatibility with any factory that does not set the name manually.

Expected behavior

When using create_task(..., name="example name"), the task's name should always be set - even when using a custom task factory - as it was before the regression.

Actual behavior

With a custom factory that returns a subclassed asyncio.Task, the task name is None unless the factory manually calls set_name(name). This is a silent behavioral change that breaks code relying on set_name() being called by the event loop.

My Environment

Python version: 3.13.2
Debian testing

Script to reproduce

import asyncio

async def main():
    names = []

    async def get_name():
        names.append(asyncio.current_task().get_name())

    async with asyncio.TaskGroup() as tg:
        tg.create_task(get_name(), name="example name")

    print(names)

asyncio.run(main())  # Output: ['example name']

def factory():
    loop = asyncio.new_event_loop()
    loop.set_task_factory(asyncio.eager_task_factory)
    return loop

asyncio.run(main(), loop_factory=factory)  # Output: ['example name']

# Fails silently with custom task_factory
result = None

class MyTask(asyncio.Task):
    def set_name(self, name):
        global result
        print(name) # never reached
        result = name + "!"

    def get_name(self):
        global result
        return result

def loop_factory():
    loop = asyncio.new_event_loop()
    loop.set_task_factory(asyncio.create_eager_task_factory(MyTask))
    return loop

asyncio.run(main(), loop_factory=loop_factory)  # Output: ['None']

CPython versions tested on:

3.13

Operating systems tested on:

Linux

[kthreadd]

Hi @sergiosacj

Yes, from #128308 on, the asyncio.BaseEventLoop.create_task() no longer calls set_name().

The name setting operation is actually done in the C function during calling create_task(..., name="example name"), not set by `set_name.

And by the way, from the code you supplied, the function get_name overwritten by MyTask, so it seems that it's the reason why names.append(asyncio.current_task().get_name()) gets None.

So, you could get correct name example name if you have a correct get_name, even you didn't set name manually via set_name(), because the name will be set by calling create_task(..., name="example name").

[sergiosacj]

The name setting operation is actually done in the C function during calling create_task(..., name="example name"), not set by `set_name.

Thanks @kthreadd, I misinterpreted then.

When I read the documentation, I thought set_name should be called in this scenario. Maybe the sentence below should be updated?

"If name is not None, it is set as the name of the task using Task.set_name()"

And by the way, from the code you supplied, the function get_name overwritten by MyTask, so it seems that it's the reason why names.append(asyncio.current_task().get_name()) gets None.

That's right, this code assumed that set_name was called inside create_task. I made this example based on this test here.

[kthreadd]

@sergiosacj, ok, I also noticed that the out of date description in document asyncio.create_task, for the same, test case is also out of date test_set_task_name

Both of them need to be updated I believe.

[picnixz]

We tracked the more general issue in #133745.