Eager task's explicitly set name is replaced

[xitop]

Bug report

Bug description:

In Python 3.13, the name assgined to an eager task is set too late. This is a known issue gh-128308.
However, when the name is being set, another name given to the task in meantime gets overwritten.

import asyncio

async def coro():
    this_task = asyncio.current_task()
    print(this_task.get_name())   # not set yet
    this_task.set_name("BBB")
    print(this_task.get_name())   # new name was set here
    await asyncio.sleep(0)
    print(this_task.get_name())   # name from create_task overwrites

async def main():
    asyncio.get_running_loop().set_task_factory(asyncio.eager_task_factory)
    task = asyncio.create_task(coro(), name="AAA")
    await task

if __name__ == '__main__':
    asyncio.run(main())

This program prints on 3.12 and 3.13 branches (tested with 3.12.12 and 3.13.11):

Task-2
BBB
AAA

(Note: 3.11 did not have eager tasks and on 3.14 is everything fine):

The first line is explained by the mentioned issue #128308. The second one confirms the name was set.
The third line is IMO not correct, because the last modification should win.

---

A variation of the reproducer without setting the name in create_task behaves a little bit different.

    task = asyncio.create_task(coro())    # removed name="AAA"

It prints an expected output on 3.12:

Task-2
BBB
BBB

but exposes another known issue in 3.13:

Task-2
BBB
None  <-- it's a string

CPython versions tested on:

3.13

Operating systems tested on:

Linux

[priyanshu2282-cyber]

I’m interested in working on this. I will try to reproduce the bug and propose a fix.

[priyanshu2282-cyber]

I reproduced this on Python 3.12 using asyncio.eager_task_factory, and it seems closely related to the behavior described in #128308.
With eager tasks enabled, it looks like the task can start executing before the explicit name= passed to create_task() or TaskGroup.create_task() is applied. Because of that, the coroutine initially observes the default auto-generated name (Task-*).

In the example from this issue, there’s an additional side effect: if the coroutine calls task.set_name() early on, that newer name can later be overwritten by the delayed internal name assignment (or even by None in 3.13). That feels unintuitive, since the last explicit name change should win.

So my current understanding is that, for eager tasks, the explicit name is applied too late and unconditionally. Ideally, the name should already be visible when the coroutine starts running, and internal logic shouldn’t overwrite the task name once it has been changed from the default.

I’m planning to add a regression test covering both create_task(name=...) and TaskGroup.create_task(name=...) with the eager task factory, and then explore a minimal fix based on that. Open to any guidance on the approach.

[picnixz]

Please avoid using LLM/AI for generating the PR as we forbid auch uses.

[priyanshu2282-cyber]

Ok, I will take care of it.