How to properly abort a pending fetch request?

[schnz]

Abstract

I am using urql together with a React app and I am desperately trying to pass a signal of an AbortController instance to a fetch request. But the signal that ends up being used by urql seems to be copied somewhere along the way and is never canceled.

Example

https://codesandbox.io/s/blue-morning-mtfj80?file=/src/App.js

What the example does

When pressing the button, the following things happen:

1. MyFetchComponent gets mounted
2. useEffect hook of MyFetchComponent runs and returns a callback that is called when the component gets unmounted. When called, it aborts the two controller instances that it created.
3. MyFetchComponent is umounted (due to Reacts development mode)
4. The callback from step 2 is called, effectively aborting the two signals which are supposed to cancel the associated requests
5. `MyFetchComponent is mounted again (again -> thats Reacts normal behavior in development mode to detect certain error classes)
6. useEffect hook runs again -> this time the requests have time to complete

When following the console output (or your network log) you will see that the urql query is never canceled. I suppose that is because the signal that I pass to the context is copied somewhere along the way and thus is no longer associated with the controller instance.

My question

So my question is: How am I supposed to abort pending requests with an abort signal?

[kitten]

There are three different cases here, and I'll ignore the specific framework bindings (like the bindings for React, for instance):

• Running a query declaratively (e.g. via useQuery or client.query)
• Running a query imperatively (e.g. via client.query(...).toPromise())
• Running a mutation

In the first case, whenever the subscription to the result disappears, e.g. useQuery is unmounted, then the Client will issue a teardown event and ensure that ongoing requests are cancelled and notify the cache that you're not interested in any further updates.

However, in the second case, once you basically use the promisifying request, or are using the Wonka streams and aren't unsubscribing, the result will be ongoing and no teardown event will be issued.

The situation does change however with mutations. In urql, we made the decision that mutations aren't cancellable. This is because in GraphQL, especially for caching, it's hard to tell whether the mutation has reached the API and there's hence no way of knowing whether it has actually been executed or not. The spec also does not accommodate any cancellation of mutations (basically, for this reason). So, there's no built-in way of cancelling mutations and it's actively discouraged, and they're often treated as fire-and-forget.

Although, in theory, you can still issue the teardown event manually, I'd simply recommend you not to do this and treat mutations as fire-and-forget events you're sending to your GraphQL API.

As per the cancellation in general, there's more details here: https://formidable.com/open-source/urql/docs/architecture/

It's also worth mentioning though that we don't make the assumption that your GraphQL operations are exclusively sent via HTTP (since the transport could be anything else as well, e.g. WebSockets), hence the API is not HTTP specific.

In your example for instance, you're passing the signal to OperationContext (See: https://formidable.com/open-source/urql/docs/api/core/#operationcontext) while the fetchExchange will instead pick up options from the OperationContext.fetchOptions property.

That said though, the AbortSignal will be overriden since it's not exposed as a public API and is instead an implementation detail: https://github.com/FormidableLabs/urql/blob/ebcde6e9395fe9ec7b583b6fef66edb2d388c08f/packages/core/src/internal/fetchSource.ts#L27-L31

[kubijo]

Pardon me if it should be clear from what has already been said, but I have a related question…

In the example below, should I get an error with an "aborted" reason, or is it expected that the library "swallows" it?
My experiments tell me that the latter is true, but I haven't been able to deduce whether that is a correct and expected behavior.

If it's relevant, I am using cross-fetch as a fetch polyfill.

From my recent experience with gRPC I am used to having to handle the aborts myself (which makes sense purely from the view of being explicit about what is happeing).

const abortCtrl = new AbortController();
abortCtrl.abort();

const { data, error } = await client.query(
    /* query */ gql`…`,
    /*  vars */ {},
    /*   ctx */ { fetchOptions: { signal: abortCtrl.signal } },
).toPromise();

[kitten]

@kubijo This won't work and abort controllers in this scenario aren't passed on to fetch. While AbortControllers are a necessary part of JS and sometimes useful it's not part of the public urql API and even if this would work and be passed on to fetch, this wouldn't be a very ergonomic API.

Cancellation is built into urql regardless of transport as well — not just fetch/HTTP so it also wouldn't be universal this way.

To keep it short, if you were to use a Source rather than promisifying the query result stream, then you get access to cancellation: https://formidable.com/open-source/urql/docs/basics/core/#subscribing-to-results

[kubijo]

@kitten

I see… me being very new to all this iterable wonderland, would you say this is a sensible wrapper around the source that would simulate the built-in toPromise behavior, but also allow cancelation?

function query(query, variables, context) {
    return new Promise(resolve => {
        const source = client.query(query, variables);
        const { unsubscribe } = wonka.pipe(
            source,
            wonka.filter(result => !result.stale && !result.hasNext),
            wonka.take(1),
            wonka.subscribe(result => {
                resolve(result);
                unsubscribe();
            }),
        );
        context?.signal?.addEventListener('abort', () => {
            unsubscribe();
            resolve({
                data: undefined,
                error: AbortErrorSingleton,
            });
        });
    });
}

[schnz]

Thank you very much for the thorough explanation and background information! I'll do as you said and treat mutations as fire-and-forget events then.

In my real application I was passing the signal to OperationContext.fetchOptions and was wondering why it ends up being a different signal than the one that I passed. So the code excerpt of yours does explain this quite well.