Cancel resolver tasks if execution of an operation is terminated
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 35/100
Rechercherichtung
Beginne damit, die Ausführung asynchroner GraphQL-Operationen nachzuverfolgen und zu untersuchen, wie Resolver-Aufgaben geplant werden, wenn ein nicht-nullbarer Resolver fehlschlägt. Reproduziere das in Issue #3414 beschriebene Strawberry-Szenario; abgeschlossen ist die Aufgabe, wenn nicht mehr benötigte Resolver-Aufgaben vor Beendigung der Ausführung abgebrochen werden und nach der Antwort oder der Bereinigung des Lebenszyklus nicht weiterlaufen.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- Python
- Sterne
- 531
- Forks
- 147
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus graphql-python/graphql-core
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 50/100
graphql-python/graphql-core#272 · 1 Kommentar ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 55/100
graphql-python/graphql-core#269 · 1 Kommentar ·
-
Publish a major version Offen
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
graphql-python/graphql-core#267 · 1 Kommentar ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100
graphql-python/graphql-core#257 ·
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
graphql-python/graphql-core#247 · 8 Kommentare ·
Alle Issues in graphql-python/graphql-core
Ähnliche Issues
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
stephrobert/dsoxlab#238 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
sublimehq/package_control#1780 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
nwg-piotr/nwg-displays#145 ·