(svelte) - "Failed to fetch" error not caught in CombinedError

[max-las]

I'm using Svelte bindings. When my API in down and I try to query it, the error Uncaught (in promise) Error: Failed to fetch is thrown, and it is not reflected in $myOperationStore.error. Instead, $myOperationStore.fetching remains true and $myOperationStore.error remains undefined. So I'm not sure how to handle that case.

Here is my code :

<script>
  import { operationStore, query } from '@urql/svelte';

  let username = null;
  let usernameError = null;
  let usernameSuccess = null;
  let usernameWarning = null;

  function resetUsername() {
    usernameSuccess = null;
    usernameError = null;
    usernameWarning = null;
  }

  const caniuse = operationStore(
    `
    query ($username: String!) {
      caniuse(username: $username)
    }`,
    { username },
    { pause: true }
  );

  query(caniuse);

  function queryCaniuse(username) {
    $caniuse.variables.username = username;
    $caniuse.reexecute({ pause: false });
  }

  $: {
    if(username){
      queryCaniuse(username);
    }else{
      resetUsername();
    }
  }

  $: {
    resetUsername();

    if (!$caniuse.context.pause) {
      if ($caniuse.fetching) {
          usernameWarning = "Checking username availability...";
      } else {
        if (!$caniuse.error) {
          if ($caniuse.data.caniuse) {
            usernameSuccess = "Username available";
          } else {
            usernameError = "Username unavaible";
          }
        } else {
          usernameError = "Something went wrong";
        }
      }
    }
  }
</script>

urql version:
@urql/svelte 1.3.3

Steps to reproduce

1. Setup an operationStore holding a query
2. Run the query while the API server is down
3. Observe the presence of Uncaught (in promise) Error: Failed to fetch in the console
4. Observe the value of the properties error and fetching of the operationStore

Expected behavior

I suppose failing to fetch should result in a networkError held in the CombinedError returned by the operationStore.

Actual behavior

Error is ignored by urql and just happens with no way to handle.

[orangecms]

Ran into this with urql (React) as well. I have found that @urql/core ends up treating this as a TypeError using a local build, thrown in fetchSource.ts. I'll see what I can figure out.

[orangecms]

Simple: If not passing a custom fetcher, urql defaults to window.fetch.
To reproduce the issue, just do this in dev tools:

fetch("http://wjejfufiiendj").catch(console.error)

Chromium 98 here logs TypeError: Failed to fetch.
How should urql behave? Pass through TypeError? (why do they even call it that? Time to read Chromium/v8 docs, MDN ...) 😅

Introduced here:
20b7951

The changelog says:

Fix error bubbling, when an error happened in the exchange-pipeline we would treat it as a GraphQL-error

[orangecms]

https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#checking_that_the_fetch_was_successful

A fetch() promise will reject with a TypeError when a network error is encountered or CORS is misconfigured on the server-side, although this usually means permission issues or similar — a 404 does not constitute a network error, for example. An accurate check for a successful fetch() would include checking that the promise resolved, then checking that the Response.ok property has a value of true.

for reference

[kitten]

I suppose this is a regression from #2210, since it 100% sounds like it, so I think I can preemptively confirm that this is a problem

[dvicory]

I can confirm we're seeing this behavior as well when the backend server is down. This caused us some interesting issues where dedup exchange would filter out reexecutions, since it believed queries were still in flight since it never received an OperationResult. There was the same uncaught Uncaught (in promise) Error: NetworkError when attempting to fetch resource.

[JoviDeCroock]

This should be fixed in @urql/core 2.4.2 by the #2287 PR