asyncio.Barrier: cancelling a waiting task mid-round can cause a later arrival to reuse its index

Bug description:

asyncio.Barrier.wait() is documented to return "a unique and individual index number from 0 to 'parties-1'" for each task that passes the barrier together. If a task's wait() call is cancelled while the barrier is still filling (i.e. before enough parties have arrived), a task that arrives afterward can be assigned the same index as another task that is already waiting in that same round — so two tasks in the same successful release get the same index, and another index in the range is never handed out at all.

Reproducer

import asyncio

async def main():
    b = asyncio.Barrier(3)
    results = []

    async def party(name):
        try:
            idx = await b.wait()
            results.append((name, idx))
        except asyncio.CancelledError:
            results.append((name, "cancelled"))
            raise

    t1 = asyncio.create_task(party("A"))
    t2 = asyncio.create_task(party("B"))
    await asyncio.sleep(0)
    await asyncio.sleep(0)

    t1.cancel()          # A leaves while the barrier is still filling
    try:
        await t1
    except asyncio.CancelledError:
        pass
    await asyncio.sleep(0)

    t3 = asyncio.create_task(party("C"))
    t4 = asyncio.create_task(party("D"))   # completes the round of 3
    await asyncio.gather(t2, t3, t4)

    print(results)

asyncio.run(main())

Output on current main:

[('A', 'cancelled'), ('D', 2), ('B', 1), ('C', 1)]

B and C both get index 1; index 0 is never handed out to any of the three tasks that actually pass the barrier together (B, C, D).

Root cause

In Lib/asyncio/locks.py, Barrier.wait() assigns index = self._count eagerly, at arrival, before the round's final membership is known:

index = self._count
self._count += 1
if index + 1 == self._parties:
    await self._release()
else:
    await self._wait()
return index

self._count is decremented again when a party leaves early (cancellation), in the finally block. Since index is derived from a counter that can both increase (new arrivals) and decrease (early departures) within the same round, a later arrival can end up with the exact self._count value an earlier, still-waiting task already captured as its own index.

This is specific to the asyncio implementation — threading.Barrier doesn't need to handle a party "un-arriving" mid-wait the way a cancellable asyncio.Task can, so the sync version doesn't have an analogous bug.

I don't see an existing report for this (checked issues/PRs mentioning asyncio.Barrier).

A working fix

Indices can't be assigned correctly at arrival time when membership can still change; they need to be finalized once the round's exact release cohort is known (at release time), assigned once from the current arrival order. I have a fix + regression test ready and will open a PR against this issue.

CPython versions tested on:

3.16 (main)

Operating systems tested on:

Linux (WSL), should be platform-independent (no OS-specific code involved)

Linked PRs

• gh-155235

Beginne mit Barrier.wait in Lib/asyncio/locks.py und führe den im Issue beschriebenen Reproducer aus, um den doppelten Index nach dem Abbruch zu beobachten. Überprüfe den verknüpften PR gh-155235 und dessen Regressionstest. Als erledigt gilt die Aufgabe, wenn das Abbruch-Szenario eine Runde mit eindeutigen Indizes für jede sie passierende Aufgabe freigibt.