TaskGroup: tg.cancel() shouldn't block create_task() allow cooperative cancellation
Personne n'a encore pris cette issue.
- Langage dominant
- Python
- Étoiles
- 77.2k
- Forks
- 35.9k
- Métriques de merge des PR
- Métriques de PR en attente
Description
Currently, when a TaskGroup is explicitly cancelled via tg.cancel(), any subsequent call to tg.create_task() raises:
RuntimeError: TaskGroup <TaskGroup cancelling> is shutting down
This contradicts the TODO in the test test_taskgroup_cancel_before_create_task, which states:
This behavior is not ideal. We'd rather have no exception raised, and the child task run until the first await.
Proposed change:
After an explicit tg.cancel() (not after a failure-induced abort), create_task() should succeed. The new task should run its synchronous code up to the first await, then receive CancelledError
For failure-driven aborts (e.g., an exception in another task), the existing RuntimeError is preserved to prevent unsafe task creation during error cleanup.
A PR implementing this change (with a new _explicitly_cancelled flag) is ready and passes all existing tests.
This resolves the TODO and makes TaskGroup behavior more intuitive when voluntarily cancelled.
Linked PRs
- gh-150357
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par le TODO test_taskgroup_cancel_before_create_task et les points d’entrée cancel/create_task de TaskGroup décrits dans l’issue. Comparez tg.cancel() explicite au comportement d’abandon déclenché par une erreur. Le travail est terminé lorsqu’une tâche créée après l’annulation explicite exécute son code synchrone avant de recevoir CancelledError, tandis que les abandons déclenchés par une erreur lèvent toujours RuntimeError.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- python
- Domaine
- backend
- Type d'issue
- Fonctionnalité
- Difficulté
- 3/5
- Temps estimé
- 1-2 jours
- Activité
- À l'abandon
- Clarté
- Clairement spécifiée
- Accessibilité débutants
- 25/100