createResource: It stops updating result when it encounters an error

[weijarz]

Playground Link

import { createSignal, createResource } from "solid-js";
import { render } from "solid-js/web";

const fetchUser = async (id) => {
  if (id % 5 === 0) throw new Error('timeout')
  return (await fetch(`https://swapi.dev/api/people/${id}/`)).json();
}

const App = () => {
  const [userId, setUserId] = createSignal();
  const [user] = createResource(userId, fetchUser);

  return (
    <>
      <input
        type="number"
        min="1"
        placeholder="Enter Numeric Id"
        onInput={(e) => setUserId(e.currentTarget.value)}
      />
      <span>{user.loading && "Loading..."}</span>
      <span>{user.error && "ERROR!"}</span>
      <div>
        <pre>{JSON.stringify(user(), null, 2)}</pre>
      </div>
    </>
  );
};

render(App, document.getElementById("app"));

After the user enters '5', the query function no longer works and can not query other numbers.
Why does it continue to query after an error but not update the results?

[atk]

The fetcher is supposed to catch errors itself and use Promise.reject to return them.

[weijarz]

const fetchUser = async (id) => {
  if (id % 5 === 0) return Promise.reject(new Error('timeout'))
  return (await fetch(`https://swapi.dev/api/people/${id}/`)).json();
}

This look does not work either.

[ryansolid]

The problem is that it is the read that throws. Either use an ErrorBoundary or guard the read with error.. ie.. don't read from the value if there is an error.

[BrandonEnclude]

Wrapping it in an ErrorBoundary still seems to break the reactivity.

Checking for errors before reading works, but is there a reason why the read needs to throw an error when the Resource already details the error? Feels cleaner for user() to return undefined if there's an error.

Edit:
Just in case anyone is still struggling, here's a working example.

[ryansolid]

Inversion of Control. Similar reason why we have Suspense. It is sort of unfortunate that in our flexibility we've gotten here. Ideally I didn't want to have the guards for things like errors because they prevent the throwing. Adding the details on the resource came later and I sort of regret it from the confusion it causes. What we want is to be able to handle these sort of things as layout components even if the resource is created further down the tree.

Do you have an example where it breaks Reactivity?

[BrandonEnclude]

Sure, here's an example where the ErrorBoundary doesn't seem to be working. It doesn't display the fallback, logs an error to the console, and the resource stops refetching.

I ended up wrapping my resource in its own store with derived signals to safely get the resource/error rather than checking for errors any time I attempt to access the value. In my case, I'm not necessarily referencing this resource in a layout component -- I have another resource that fetches based on on the value of this one. Not sure what the correct terminology is here, but I want to think of it as a service. Am I designing an anti-pattern? Any suggestions on how to implement this?

Edit:
After playing around a bit, it's the Match component that prevents the ErrorBoundary from working correctly. Here's another example where it sort of works, except the ErrorBoundary still prevents the resource from refetching.

[ryansolid]

Yeah it does seem like Switch/Match don't appreciate ErrorBoundaries in the middle which probably will take some looking as it is a very specific setup.

But your other example is good and probably where we need to figure out what makes sense better. The problem is that Error Boundaries need to be reset. The Error needs to be cleared as Solid doesn't re-render. Each error boundary exposes a reset and solid-js itself exposes a resetErrorBoundaries. But figuring out how to trigger that at the right time requires some though.

One thing that I've done is to have them always reset on router navigation. But obviously cases like this are still unintuitive. We could look at resetting on all resource resolution, or when any resource removes its error state if it was errored previously. That would solve this scenario. But I'm still trying to think of what the desired behavior is.

If we reset on resources it would behave something like this: https://playground.solidjs.com/?hash=703989780&version=1.4.1. Which I'm gathering is what you were expecting?

[deluksic]

For people coming to this thread, it is very important that in the solution with resetErrorBoundary, reset comes after setting the next state like in the example by @ryansolid and not before:

onInput={(e) => {
    setUserId(e.currentTarget.value);
    // after!
    resetErrorBoundaries();
}}

Edit: Otherwise the error lingers for one more state change

[AhsanAyaz]

@ryansolid I'm working on a creating a solidjs crash course and facing the same issue.

export const fetchSelectedRequest = ({ params }: RouteDataFuncArgs) => {
  const [request] = createResource(
    () => params.id,
    () =>
      new Promise((resolve, reject) => {
        setTimeout(() => {
          const match = restRequests()?.find((r) => r.id === params.id);
          if (!match) {
            throw new Error("WhAT"); // or use reject("Request not found");
          }
          resolve(match);
        }, 500);
      })
  );
  return request;
};

Template:

<Switch>
  <Match when={request.loading}>
    <div>Loading...</div>
  </Match>
  <Match when={!request.loading && request()}>
    <RestClientForm
      request={request()}
      actionBtnText={"Send"}
      formSubmit={onFormSubmit}
      formUpdate={onFormValUpdate}
    />
  </Match>
  <Match when={request.error || !request()}>
    <div>Request Not found</div>
  </Match>
</Switch>

The request.error doesn't work as all of this results in an error 🙂

I believe one would assume that the createResource() would catch the error. But it doesn't. I'm finding it hard to explain a logical reason for this in my tutorial 😅

[oceantume]

Indeed, I'm testing out SolidJS and I'm very curious to get more information about this.

The docs clearly state that this should be possible. While error boundaries work and catch the error expectedly, I'm left wondering how createResource is ever supposed to return with state: 'errored' considering it doesn't catch promise rejections (async), runtime errors (sync) and doesn't handle return Promise.reject(err) or return new Error() for the fetcher.

[ryansolid]

@AhsanAyaz
The problem here looks like you are throwing from a setTimeout. That code runs from its own execution stack independent of the promise. There is no connection to where that code runs and the outer context. It would be uncaught since the timeout doesn't realize that it is being instantiated in a promises constructor. The runtime stack at that time is literally just that timer function being called.

@oceantume
createResource does catch errors: https://github.com/solidjs/solid/blob/main/packages/solid/src/reactive/signal.ts#L654. So not sure what is going on there.
We catch them and store them so that you can read them or if someone accesses the resource data signal it throws from that point.

[kakserpom]

@AhsanAyaz That's no wonder. throw new Error("WhAT") is inside a setTimeout callback, it cannot be caught outside the callback. Javascript 101.

[GuusPlx]

@ryansolid is it possible for your to provide a working example of a createResource with an error state? I'm also confused and don't seem to get createResource to return state: 'errored'. This example is also a good addition to the current docs chapter for "createResource". Error handling is hard and full examples help developers like me and @oceantume .

[mrcaidev]

I also found the error handling of createResource a little confusing, but this official youtube video seems to have provided a more detailed explanation than the docs.

It would be nice if we can have more details about it in the docs.

And I'm recording the problem I encountered when using Switch + Match with createResource below, which may be of some help if someone has run into the same issue and happens to find this page.

This works:

<Switch fallback={<div>Fallback</div>}>
  <Match when={data.loading}>
    <div>Loading</div>
  </Match>
  <Match when={data.error}>
    <div>Error</div>
  </Match>
  <Match when={data()}>
    <Data data={data()} />
  </Match>
</Switch>

But this don't (ErrorBoundary needed):

<Switch fallback={<div>Fallback</div>}>
  <Match when={data.loading}>
    <div>Loading</div>
  </Match>
  <Match when={data()}>
    <Data data={data()} />
  </Match>
  <Match when={data.error}>
    <div>Error</div>
  </Match>
</Switch>

[yonathan06]

Thanks! that definitely works :)
the video is not available on youtube anymore, do you remember it's title?

[ni554n]

Video is not archived but you can see the description here: https://web.archive.org/web/20230407101023/https://www.youtube.com/watch?v=A5_58oenCqk

[Morgenstern2573]

Just in case anyone else is confused, the reason the second example doesn't work is because the attempt to read data in when={data()} creates an error when the fetcher errors out/rejects. The first example works because it checks for data.error before the attempt to read.

[mrcaidev]

the video is not available on youtube anymore, do you remember it's title?

Sadly no :(

[sparecycles]

Hello from 2024, I'm also suffering from this issue and my use-case seems to be slightly different:

const [resource] = createResource(input, () => await process(input()); }

All I want from the resource in my case is resource.latest and resource.error, but the createResource() stops reacting to changes in input after the first error.

[noveogroup-amorgunov]

Hi, I got a similar issue (the component doesn't respond after the resource throws an exception) and I have a few thoughts:

• First, as I understand it, the problem can be solved using ErrorBoundaries + resetErrorBoundary, and this works (if anyone else faces a similar issue, here's an example of how to solve it: https://playground.solidjs.com/anonymous/d95f15fa-f042-43bc-92ba-efea089bbe60). However, it seems strange to me that resetErrorBoundary is not mentioned in the documentation.

• Second, a more correct solution would be to use some data fetching pattern and not throw an exception, but return an object with an error if one occurs. It would be great to have such an example in the official documentation.