Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Cancel resolver tasks if execution of an operation is terminated

Ouverte
#217 8 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
graphql, python
Domaine
api, backend

Piste de recherche

Commencez par suivre l’exécution des opérations GraphQL asynchrones et la manière dont les tâches des resolvers sont planifiées lorsqu’un resolver non nullable échoue. Reproduisez le scénario Strawberry décrit dans l’issue #3414 ; le travail est terminé lorsque les tâches des resolvers devenues inutiles sont annulées avant la fin de l’exécution et ne continuent pas après la réponse ou le nettoyage du cycle de vie.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

help wanted investigate
TL;DR

Would it be possible to cancel outstanding resolver tasks as soon as before execution of a GraphQL operation is terminated? Outstanding / unused tasks can happen as a result of an incoercible field resolver error.

These outstanding tasks can run well after lifecycle hooks responsible for cleaning up their context have completed. As a result, they often fail and cause a lot of noisy errors for us.

More details

Hello!

I'm coming from the strawberry-graphql project. We're running into a problem with abandoned resolver tasks not being cancelled, and thus failing in unpredictable ways.

Strawberry has an extensions framework which allows you to wrap the execution phase of your operation processing in hooks – running code before and after execution of resolvers. We use these hooks to manage (set up and tear down) some state needed by the resolvers.

However, when a resolver of a non-nullable field fails, it may lead to the results of some other resolvers being no longer necessary. It appears that graphql-core will then short-circuit returning a result, while the no-longer-necessary resolvers are still running. We see that they can continue running well after the HTTP response was returned.

The problem is that Strawberry's lifecycle hooks (and I also imagine - the webserver's) would have completed by that time. As a result, we do things like terminate the DB session – making it very likely that these outstanding tasks will fail with various esoteric errors. This causes a lot of noise in our observability suite – which we'd love to avoid.

See https://github.com/strawberry-graphql/strawberry/issues/3414 for more details, and https://github.com/strawberry-graphql/strawberry/issues/3414#issuecomment-2012060461 for the comment which recommends I report the issue here.

Langage dominant
Python
Étoiles
531
Forks
147
Métriques de merge des PR
Aucune PR mergée en 30 j

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de graphql-python/graphql-core

Toutes les issues de graphql-python/graphql-core

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.