fetchOptions and AbortController

[bigescalade]

Hello

We are using urql to create a hybrid app where we use the offlineExchange for some optimistic submissions, but require the user online for important submissions. Because we use the offlineExchange network errors do not bubble up, and fetch requests never timeout if the device is offline.

To get around this I am trying to use the fetchOptions to setup an AbortController to timeout requests after X seconds (for testing its set to 1 second)

The code looks like this

       fetchOptions: () => {
         const controller = new AbortController()
         setTimeout(() => {
           controller.abort()
         }, 1000)

         return {
           signal: controller.signal,
         }
       },

The problem is that after 1 second the request does not time out as expected. Has anyone had any success in timing out a fetch request when using the offlineExchange?

[kitten]

There's a couple of things to unpack here and the offlineExchange's behaviour may also be tweaked in the future to accommodate to some of the use-cases we've now heard of or seen, but until then there's a couple of things to keep in mind.

Because we use the offlineExchange network errors do not bubble up

This thread had a couple of explanations on the specific error behaviour: #1520 (comment)

Specifically, mutation errors will always bubble up, even when you're offline, as network errors. Queries and optimistic mutations are the ones that may silently fail in the background, optimistic mutations fail silently, because they will still be reflected in the UI and will be resent when online again, and queries because the offlineExchange will make a best effort to deliver as much data as it has while offline (delivering null when it can't)

However the errorExchange still allows you to observe all "hidden errors", so to speak, by placing it after the offlineExchange since it'll then see the network errors that the fetchExchange generates/receives.

and fetch requests never timeout if the device is offline.

Offline is a bit of a "misnomer" here; I've often seen that fetch requests will be sent until the very last default timeout (sometimes up to 300 seconds) when the device isn't in fact offline, as in, if it's network connection is established but unusable. Some offline simulations also don't work correctly and instead make fetch requests just never respond, which isn't optimal.

The thing to understand here is how offlineExchange detects offline scenarios. In your case, the device doesn't actually think it's offline (if it was, you'd get an error sooner) so the timeout does make sense conceptually. The thing to keep in mind though is that the offlineExchange won't definitively accept that it's offline until this condition is met: https://github.com/FormidableLabs/urql/blob/8acc61d101a820046b3b5005e342a4888f4c8e01/exchanges/graphcache/src/offlineExchange.ts#L59-L66

Specifically, it detects the kind of error (although it can also fall back to navigator.onLine) and reads the raw message. So when you're imitating the offline state with a timeout you need to make sure that you actually issue an error that matches this, if you do want to treat a timeout like an offline state. It may be better to not only have a timeout but also add a bit of retry logic to ensure that you've really tried to start the request over a couple of times: https://formidable.com/open-source/urql/docs/advanced/retry-operations/

Now, the last thing is that you should not use the Client's fetchOptions or fetch parameter to extend urql if at all possible. That's what exchanges are for. That's especially important here because urql's internal fetchExchange (and other related fetch-exchanges) already have built-in cancellation logic, because if a query is not consumed by parts of the app anymore, the Client is able to proactively "tear down" all state that is related to it, a special operation that's called a teardown (rather than a query or mutation). There's some more information on that on the Architecture page of our docs: https://formidable.com/open-source/urql/docs/architecture/

But let's get to actually talk about how you could implement an explicit timeout.

You'd likely want to write an exchange that: (1) sets a limit on how long the fetchExchange should take, and (2) issues a network error, or at least an error that looks similar to one so that the offlineExchange picks it up as such.

import { Exchange, makeOperation } from '@urql/core';
import { pipe, share, mergeMap, merge, filter, fromValue, delay, takeUntil, onPush } from 'wonka';

export const timeoutExchange = ({ timeout = 1500 }): Exchange => ({ client, forward }) => {
  return ops$ => {
    const sharedOps$ = share(ops$);
    const sharedResults$ = pipe(ops$, forward, share);
    
    // For each operation we construct a "timeout limit"
    const timeoutResults$ = pipe(
      sharedOps$,
      mergeMap((operation) => {
        // This listens to teardowns, i.e. other, unrelated cancellations per operation
        const teardown$ = pipe(
          sharedOps$,
          filter(op => op.kind === 'teardown' && op.key === operation.key)
        );
    
        // This listens to results per operation
        const result$ = pipe(
          sharedResults$,
          filter(res => res.operation.key === operation.key)
        );
    
        return pipe(
          // This value will be emitted unless some other preconditions are met (it's a timeout network error)
          fromValue(makeErrorResult(
            operation,
            new Error('Network Error: Request timed out')
          )),
          // First we delay this result by the timeout
          delay(timeout),
          // Then we'll only take its value if it comes before a given cancellation or other result, as defined above
          takeUntil(merge([teardown$, result$])),
          // Otherwise we'll also issue a cancellation to the client ourselves, to stop the request
          onPush(() => {
            client.reexecuteOperation(makeOperation('teardown', operation))
          })
        );
      })
    );
    
    // This means we let all results through, but we add on our timeouts' results
    return merge([sharedResults$, timeoutResults$]);
  };
};

I haven't really tested this thoroughly, but I left some comments to elaborate what it does;

[bigescalade]

Thanks for the reply really appreciate it, especially taking the time to write out a timeoutExchange which I'll be playing with immediately! We might need to rethink our strategy here to fall in line with urql and work with it - rather than work against it. Will first start working with the errorExchange (i think we placed it in the wrong spot initially) and see if that gets us what we need, as well as work with the retryExchange

EDIT: yeah we had the errorExchange in the wrong spot, I see it working now

[bigescalade]

Just implemented the timeoutExchange and it worked just by dropping it in! Your comments in the code help me understand, I'll have to do more reading on observables to fully understand. We now get the desired result we've been looking for.

[bigescalade]

Hi @kitten

Testing the timeoutExchange I set a timeout of 3000ms. The first couple of requests successfully timeout in 3000ms however subsequent requests don't timeout. There doesn't seem to be a pattern to how many times a request will stop timing out, sometimes it happens after 3 sometimes it happens after 7.

I've put logs in the timeoutExchange and it seems that the timeoutExchange isn't hit when this occurs so I don't believe the issue is with the timeoutExchange.

I've implemented the devtools and I can see the request will fire off:

query
teardown
query
after 3000ms teardown

Is it normal to see each request fire off two queries? I’m guessing thats happening due to a re-render of the component as the hook fires off immediately when the component mounts. The logs query logs look identical, I could not tell any difference between them

Wondering if you might have an idea on what might cause the timeoutExchange to stop being hit?

[jbayotlang]

Hi @bigescalade I'm looking into implementing a timeout exchange in my end and fortunately had a run through with this discussion. I tried using the code above by @kitten but for some reason when I'm having a compile error, TypeError: a[c] is not a function, it's pointing to this bit right here

const sharedResults$ = pipe(ops$, forward, share);

Any ideas on why it's throwing the error?