Attach AbortSignal to context by default 🤔

[n1ru4l]

This would be handy for canceling ongoing stuff within GraphQL resolvers 🤔

[robertherber]

This would be awesome 👍 I think I can provide some useful input on which capabilities would be nice since I'm currently setting working with AbortSignals in our Fastify/Yoga/GraphQL/MongoDB environment. Our use case is working with large datasets we sometimes trigger really slow queries, and as such want to cancel all requests (including database requests) after a certain timeout to clear up resources. Aborting on "client closed" is also nice but in our case not the main use case.

As a whole I'd like a solution that supports these scenarios:

• Exposing an AbortSignal through context so it can be used on any API supporting it in the resolvers (the obvious part I guess). This is fairly easy to do "manually" but having a standard would be nice.
• Make sure the AbortSignal prevents any new resolvers from triggering after an abort, this is something I haven't looked into but would be very nice I think.
• Make it possible to specify a request timeout for the AbortSignal.
• Be able to access how much time is left until this timeout (MongoDB for example doesn't support AbortSignal but can be called with cursor.maxTimeMS(ms) to ensure it times out)
• It would be nice to be able to "bring your own" AbortSignal, if you want to handle the specifics on a web server level (ex: in the timeout case I feel it makes sense to initialize the AbortSignal onRequest in my Fastify server, and it also supports our REST routes).
• Handling the abort response in a standard manner. I'm currently leaning towards plain HTTP 504 (Gateway Timeout) and 499 (Client Closed) responses since it would deal with all cases the same way.

I'm thinking to keep things simple one option would for Yoga to initially just provide:

1. A standard way to pass the AbortSignal to resolvers through context (i.e. you have to "bring your own" AbortSignal)
2. Preventing new resolvers from triggering after an abort

And maybe at a later stage provide a default AbortSignal implementation supporting the request timeout and client closed cases? What do you think?