While writing documentation forasyncio.TaskGroup I discovered something fishy.

There is a behavior where if a task fails with an exception (exceptasyncio.CancelledError), the remaining tasks are cancelled. There is also a rule that this is only done once, implemented usingself._aborted, which is set byself._abort().

But what should happen if new tasks are createdafterself._abort() is called, and one ofthose tasks fails? Then the remaining new tasks are not cancelled. To repro, we need something that creates two tasks, where the first one fails, and the second catchesasyncio.CancelledError and when caught creates two more tasks. The third task would then fail, and the fourth task might wait for ever, never getting cancelled.

Is this a bug (or design flaw)? I think we decided we would support task creation during the wait (even though EdgeDb's TaskGroup disallowed it) so that it's possible to dynamically create new tasks forever -- this seems useful. But I'm not sure we thought deep about whether to allow creating new tasks once we're waiting for allcancelled tasks to finish.

How would we fix it? Disallowing new task creation onceself._aborted is set seems excessive, since it would disallow legitimate creation of new tasks during cleanup. We could keep a weak set of tasks that we haven't cancelled yet, and if one of those fails we could cancel all others in that set (and remove them from the set) -- this would essentially create successive "generations" of tasks that live or die together (starting a new generation once any member of the current generation dies). Is this worth it?

CC:@njs@Tinche@agronholm -- I assume this problem doesn't exist in Trio because of its level-triggered cancellation, but maybe one of you still has a useful insight.