Vue is not catching errors on server side in SSR when using async child setup

[Gwynerva]

Vue version

3.5.13

Link to minimal reproduction

Vue SFC Playground

Steps to reproduce

Just open a link and you will see errors when SSR is ON.
When SSR is OFF everything works as expected.

Also, commeting the line with top-level await (making Comp.vue a sync component) will also work fine both with and without SSR.

What is expected?

In SSR mode the page is expected to be blank white for 1 second and then display error message from App.vue.
This works as expected with SSR turned off.

Basically onErrorCaptured should be triggered, child setup and <template> render immediately stopped and error message from parent component shown.

What is actually happening?

In SSR mode the page is blank for 1 second but then it tries to render the <template> of Comp.vue using the data that might not even exist (because it appears in setup after throwing error).

And even if it manages to render <template> correctly, it still does not trigger onErrorCaptured in App.vue and do not switch to show error message.

Any additional comments?

I am building a custom rendering package built on top of Vue and it heavily uses structures like these:

 // Wrappers are supposed to catch ALL errors and throws in child <Block /> and show nice error message

<BlockWrapper>
    <Block ... />
</BlockWrapper>

<BlockWrapper>
    <Block ... />
</BlockWrapper>

<BlockWrapper>
    <Block ... />
</BlockWrapper>

...

Because of this bug OR my misunderstanding of how to handle async errors in Vue 3, even when thrown it still tries to render child block's <template> even with missing data (because setup is stopped executing), throws on reading properties of non-existing objects and the whole Nuxt page breaks.

Please, don't tell me this is a no-fix. It would be a disaster... 😭

[Gwynerva]

I did some research and it turns out onErrorCaptured is not related to this bug.
There is something wrong happening with Vue on server side.

Calling setup directly in wrapper component does not help too.
Here is an example where I create a deep copy of child component and try {} catch {} it's setup directly in wrapper and it still tries to render it's <template> on server side and fails to get bar.val from setup because bar is not existing!

If we remove connections to setup function in child component we can see that Vue on server side actually detects an error but for some reason still just renders the child's <template> which is: I am just a Paragraph. Bar: REMOVED. And then on client side it catches the error again and this time show actual error message (and log hydration mismatches)...

Also in the picture you can see that when compiling on server-side Vue calls the child async setup and when it is done it stops compilation. Error is also detected, but after module is built!

So it seems Vue on server side can't catch an error and renders the child's template (if it can do it). And only on client side it actually can catch an error, stop child component from executing and display correct error message. But this causes hydration mismatch...

[noootwo]

The error threw in setup is correctly be caught:

core/packages/runtime-core/src/component.ts

Lines 884 to 891 in 833f9ea

	// return the promise so server-renderer can wait on it
	return setupResult
	.then((resolvedResult: unknown) => {
	handleSetupResult(instance, resolvedResult, isSSR)
	})
	.catch(e => {
	handleError(e, instance, ErrorCodes.SETUP_FUNCTION)
	})

Therefore, regardless of whether the setup is executed successfully or not (whether there is a correct setupState), the component will be rendered:

core/packages/server-renderer/src/render.ts

Lines 117 to 119 in 833f9ea

	// Note: error display is already done by the wrapped lifecycle hook function.
	.catch(NOOP)
	return p.then(() => renderComponentSubTree(instance, slotScopeId))

If the setup executed failed, means will render component with an empty setupState.Is this the expected behavior?

[Gwynerva]

Well this behaviour is really confusing and right now I don't have even an idea of how to catch async child errors in parent wrapper... I tried onErrorCaptured, deep copying child setup, passing error ref to child as a prop and etc.

All these solutions just fail because Vue on server-side tries to render template with broken setup state first, which 99% will cause more unhandled errors inside onErrorCaptured or catch and these errors propagate all the way up to the App root breaking the whole page (in case of Nuxt).

So I desperately need either a fix or workaround 🥲
In my package I heavily use components like <Render ...> recursively and because of this behaviour Vue even when error is thrown still tries to render child's <Render> with broken or non-existing setup variables, which is likely to call it's own <Render> and this hell goes on...

The only ugly workaround-like is to write child <template> checking every (!) setup property on undefined...
But this is kind of horrible and feels fundamentally wrong.

[noootwo]

The example without Suspense and SSR, catch the error in setup and render.
The example with Suspense and without SSR, only catch the error in setup, and skip render the component which execute setup failed.

It seems like there are different behaviors in different situations, which one is expected? @edison1105

[Gwynerva]

@noootwo Can you please give me an example with Suspense (which is turned on by default in Nuxt on root level) and SSR enabled? I tried to create a workaround yersterday for hours and failed. I am rather new in Vue.

[noootwo]

@noootwo Can you please give me an example with Suspense (which is turned on by default in Nuxt on root level) and SSR enabled? I tried to create a workaround yersterday for hours and failed. I am rather new in Vue.

@Gwynerva Can you use try/catch to handle the error in sub-component's setup? Like this, I'm not sure if this is what you need.

[Gwynerva]

Unfortunately, the whole point in my library is that wrapper handles the error and adds some handy UI, while child component can be almost anything: KaTeX formula, image, paragraph and etc. Child components are external, often provided by other libraries. And if something goes wrong it is a wrapper that has to catch any errors and display nice error message.

Handling errors inside child component eliminates one of main purposes of the wrapper — providing same error design no matter what wrapper is rendering inside. I tried to pass error ref as prop to child and use onErrorCaptured inside child but it fails anyways.

In my situation handling errors in child is a bad practice, because children are supposed "by design" to throw if something goes wrong so wrapper could nicely tell user about a problem in unified way.

Observable block system is a good example of what I am trying to do with Vue.

[noootwo]

Unfortunately, the whole point in my library is that wrapper handles the error and adds some handy UI, while child component can be almost anything: KaTeX formula, image, paragraph and etc. Child components are external, often provided by other libraries. And if something goes wrong it is a wrapper that has to catch any errors and display nice error message.

Handling errors inside child component eliminates one of main purposes of the wrapper — providing same error design no matter what wrapper is rendering inside. I tried to pass error ref as prop to child and use onErrorCaptured inside child but it fails anyways.

In my situation handling errors in child is a bad practice, because children are supposed "by design" to throw if something goes wrong so wrapper could nicely tell user about a problem in unified way.

Observable block system is a good example of what I am trying to do with Vue.

Sounds you can do like this, but this is just temporary measures. After this issue is resolved, there should be more humanized approaches available.

[Gwynerva]

Still not applicable because it requires handling the error inside the component where is was thrown. And I plan to have like a few dozens of such "child" components, and all of them can pontentially throw... I really need to handle errors in wrapper, and this wrapper is a "physically" different component, outside of child component. The only possible connections would be possible with props, but still onErrorCaptured would be a perfect solution here.

<Wrapper> // Part of base library, provides info about <Child> and also catches its errors
    <Child /> // Can be an external, can throw, can do anything...
</Wrapper>

<Wrapper>
    <Child />
</Wrapper>

<Wrapper>
    <Child />
</Wrapper>

Anyways, thank you, I think your example will do for testing purposes for now to prevent the whole page crashing on every error. But this is unfortunately not a workaround :(

This seems like a rather serious SSR issue to me because right now onErrorCaptured simply does not do what it must do.
It does not stop Vue from rendering child <template> even if child <script setup> failed.

@edison1105

[edison1105]

The example without Suspense and SSR, catch the error in setup and render. The example with Suspense and without SSR, only catch the error in setup, and skip render the component which execute setup failed.

It seems like there are different behaviors in different situations, which one is expected? @edison1105

These two examples capture the same error messages. Below are the modified versions, please observe the console.log
without Suspense and SSR
with Suspense and without SSR

When wrapped inside Suspense, the error message is not displayed because of error.value = e triggers an update of Suspense, causing the Comp not to resolve. I don't think this can be considered a bug.

[edison1105]

The original issue arises because we catch exceptions during client-side rendering execution at

core/packages/runtime-core/src/componentRenderUtils.ts

Line 94 in a038505

render!.call(

However, on the server-side, we don't catch exceptions at

core/packages/server-renderer/src/render.ts

Line 192 in bf3d9a2

ssrRender(

I think this should be fixed.

[Gwynerva]

I would argue about "minor" because in my opinion using standart onErrorCaptured on async components is not something very specific, and intent to catch async errors is rather common thing, not an edge case. In fact, I am surprised to be the first one to report it...

Either way, it's nice to know it's not a problem on my end. Very much looking forward to the fix, as there is no way to workaround it and the bug is extremely annoying.

[edison1105]

@Gwynerva
If possible, you can throw the exception in onServePrefetch, it will be correctly handed.

[Gwynerva]

@edison1105 Does not seem to work or I am doing something wrong?

Also, is there a way to use your PR instead of main version of Vue?
I tried "vue": "vuejs/core#edison/fix/12575" but that did not work.

[edison1105]

@Gwynerva

@edison1105 Does not seem to work or I am doing something wrong?

Also, is there a way to use your PR instead of main version of Vue? I tried "vue": "vuejs/core#edison/fix/12575" but that did not work.

Oh, I made a mistake onServePrefetch will not work on this scenario because there is no patch on SSR. You can try the preview package of #12601 via:

npm i https://pkg.pr.new/vue@12601

[Gwynerva]

@edison1105 This does not work with bun, but I installed it in different folder and just copy/pasted the new files inside my project.

Now, it does not crash the whole page (which is super cool) but still tries to render template causing error and hydration mismatches.

As you can see the first error is the error I throw. But then it errors again trying to access non-existing properties of failed setup.

[edison1105]

@Gwynerva
Could you please provide a reproduction that includes these error details? It can be a github repository, preferably simplified by removing unnecessary deps. I will take a closer look at it.

[Gwynerva]

@edison1105 Sadly, I can't use your PR on Vue SFC Playground. But I made a StackBlitz demo with your PR and reproduced the same example as in first post.

Right now it does not even catching errors in sync Comp setup (with Promise line commented). And still not working with async Comp setup (when Promise line is uncommented).

Expected behaviour: both sync and async Comp throw calls must result in showing div with "Error: Back to App.vue" text and NOT even try to render Comp because it's <template> references non-existing setup properties.

[edison1105]

@Gwynerva
Playground with PR #12601

[Gwynerva]

@edison1105 Now it is working with async Comp and not working with sync Comp (try commenting and uncommenting await ... Promise line in Comp.vue). And this bug works even when SSR is turned off, also in both (async and sync) cases it warns in console 🤣

To be more precise, it actually "kind of" works, but instead of my own error message "Back to App.vue" it shows an error from render when accessing unexisting properties, meaning it for some reasons still tries to render Comp.vue template even when it's setup failed.