jQuery.ajax errors are not caught by error boundary when useErrorBoundary: true

[dtinth]

Describe the bug

When jQuery.ajax (or jQuery.getJSON) rejects, it is expected that the error boundary will be invoked when useErrorBoundary: true.

However, it causes the Suspense fallback to be displayed instead.

Your minimal, reproducible example

https://stackblitz.com/edit/vitejs-vite-1b86rz?file=src/App.jsx

Steps to reproduce

Look at the text displayed on the repro.

Expected behavior

It should say "Error caught" because jQuery.ajax promise rejected (not "Suspend").

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

• OS: macOS
• Browser: Chrome

react-query version

4.14.1

TypeScript version

No response

Additional context

No response

[TkDodo]

$.getJSON is not returning a resolved or rejected promise. It returns an object that kinda looks like a promise? It's certainly not an error.

So when we throw it, react thinks it's a promise and picks it up. You probably need to wrap this thing in a real promise, and resolve it in the onSuccess callback, and look at the status and reject it accordingly.

[dtinth]

@TkDodo $.getJSON does not return an actual Promise object, but according to the docs it returns a jqXHR object, which implements the Promise interface, i.e. it is a PromiseLike.

I have updated the repro to wrap it with Promise.resolve to convert it into a real promise:
https://stackblitz.com/edit/vitejs-vite-1b86rz?file=src%2FApp.jsx

Now I get a real promise that actually rejects:

However the repro still exhibits the same behavior— even with a real rejected Promise, it is still not caught by the ErrorBoundary.

Upon further inspection, that Promise’s rejection reason is an object that contains a .then() method (i.e. a PromiseLike). The resulting behavior seems to be as you said — React thinks it’s a Promise, and triggers a Suspense instead of ErrorBoundary. It seems that this is React’s internal undocumented behavior.

So this means when using useErrorBoundary, the queryFn must never throw any object that resembles a Promise. This case is not documented (on the contrary, the documentation specifically says that errors will propagate to the “nearest error boundary”), so I am surprised to see this behavior.

Maybe the documentation should mention this edge case? I have spent more time than I would like to in debugging this issue. If that sounds good I can submit a PR.

[TkDodo]

So this means when using useErrorBoundary, the queryFn must never throw any object that resembles a Promise.

This is because you're also using the (experimental) suspense feature. Suspense is triggered by throwing a Promise. This is how react wants us to do it, until the use hook is ready.

Maybe the documentation should mention this edge case? I have spent more time than I would like to in debugging this issue. If that sounds good I can submit a PR.

It is clearly documented that you must return a rejected Promise (or throw from an async function) to have react-query pick things up as an "error". Only then it can be propagated to the error boundary.

[dtinth]

@TkDodo

This is because you're also using the (experimental) suspense feature. Suspense is triggered by throwing a Promise. This is how react wants us to do it, until the use hook is ready.

I did not enable the suspense feature in the repro — only useErrorBoundary. I am currently not using suspense: true with React Query (because as you said, it is an experimental feature).

The reason there is <React.Suspense> in the component tree is because in an app where I encounter this issue, I am only using React.Suspense with React.lazy (which is not experimental). So it kinda surprises me when React Query happens to suspend the rendering when I did not enable the suspense feature.

It is clearly documented that you must return a rejected Promise (or throw from an async function) to have react-query pick things up as an "error". Only then it can be propagated to the error boundary.

This is the query function in question:

() => {
  return Promise.resolve($.getJSON('https://api.github.com/repos/bogus/bogusbogus'))
}

When I run this function in the JavaScript console, the output below shows that it is indeed a rejected Promise:

It seems that the code is already returning a rejected Promise, am I missing something?

[TkDodo]

I did not enable the suspense feature in the repro — only useErrorBoundary. I am currently not using suspense: true with React Query (because as you said, it is an experimental feature).

right, I saw the suspense boundary but not that suspense wasn't set on useQuery. sorry.

You are right in that you are rejecting the Promise. The thing is:

• the way to trigger an Error Boundary is to throw an Error.
• the way to trigger a Suspense Boundary is to throw a Promise. That has always been experimental, and react will change this to the use() hook.

So right now, if you have an Error that looks like a Promise, and we throw that, it seems that React thinks this is a Promise and will show the suspense Boundary. I think this is just coincidental and unfortunate. Two things will make this better:

1. The use hook, because suspense boundaries will not be triggered by throwing a Promise anymore
2. In v5, we'll make it mandatory to wrap rejected Promises in Errors, thus disallow throwing arbitrary stuff. See more in the roadmap under "make TError default to Error instead of unknown".

[dtinth]

@TkDodo Really cool — seems that both things will resolve this issue I have.

I look forward to v5 and I just learned that the use hook will replace the current suspence behavior in React. Thanks for taking the time to explain this issue — very much appreciated.