Skip to content

defineAsyncComponent onError #7661

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
nestle49 opened this issue Feb 6, 2023 · 15 comments
Open

defineAsyncComponent onError #7661

nestle49 opened this issue Feb 6, 2023 · 15 comments
Labels
has workaround A workaround has been found to avoid the problem scope: ssr

Comments

@nestle49
Copy link

nestle49 commented Feb 6, 2023

Vue version

3.2.45

Link to minimal reproduction

https://github.com/nestle49/FoodSoul

Steps to reproduce

For reproduction:

  1. Install packages yarn && yarn dev
  2. Inside src/pages/MainPage.vue change params inside in this line on non-exist, for example 'Test2'
    const { dynamicLoadComponent } = useDynamicLoadComponent('Test');
  3. Refresh page -> infinity loading

If remove onError, SPA working fine

For any projects:

  1. Create SPA with vue & vite ssr;
  2. Create dynamically component with defineAsyncComponent;
  3. Use onError callback inside defineAsyncComponent on ssr;

Crash application with error on server side:
Error: [[email protected]] Hook timeout: the render() hook of /renderer/_default.page.server.ts didn't finish after 40 seconds

On client side everything is fine

What is expected?

SPA works with ssr

What is actually happening?

Error: [[email protected]] Hook timeout: the render() hook of /renderer/_default.page.server.ts didn't finish after 40 seconds

System Info

System:
    OS: macOS 13.0.1
    CPU: (8) arm64 Apple M1
    Memory: 327.75 MB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
Binaries:
    Node: 16.15.0 - ~/.nvm/versions/node/v16.15.0/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v16.15.0/bin/yarn
    npm: 8.5.5 - ~/.nvm/versions/node/v16.15.0/bin/npm
Browsers:
    Chrome: 109.0.5414.119
    Firefox: 106.0.1
    Safari: 16.1
npmPackages:
    vue: ^3.2.45 => 3.2.45

Any additional comments?

No response

@nestle49
Copy link
Author

@yyx990803 Can u comment, please?

@nestle49
Copy link
Author

@yyx990803 still relevant

@DaniilIsupov
Copy link

I confirm problem and also waiting for solution

@nestle49
Copy link
Author

@yyx990803
Can we expect to fix at least critical problems of core in the near future?

@nestle49

This comment was marked as spam.

@nestle49

This comment was marked as spam.

@nestle49

This comment was marked as spam.

@nestle49

This comment was marked as spam.

@nestle49

This comment was marked as spam.

@nestle49

This comment was marked as spam.

@LinusBorg
Copy link
Member

LinusBorg commented Mar 31, 2023

I understand you are waiting for a resolution. But if you keep this up you will be banned from the vuejs org. This is your fierst and final warning.

@LinusBorg
Copy link
Member

LinusBorg commented Mar 31, 2023

This user has now been blocked for 7 days.

We will still investigate and fix this issue once we have the capacity for it.

As a workaround for other people, consider conditionally adding this callback on on the client.

If you need it on the server, please describe the specific use case.

@GandjaFuzz
Copy link

have same issue @LinusBorg

@LinusBorg
Copy link
Member

LinusBorg commented Mar 31, 2023

Can you provide any more info about your use case?

@LinusBorg
Copy link
Member

LinusBorg commented Mar 31, 2023

So, here's what can halfway solve the issue in my quick experiment so far:

  1. make sure you provide an errorComponent and
  2. call fail() in the onError callback:
errorComponent: () => h('div', {}, 'Error!'),
onError: async (error, retry, fail) => {
    console.error(error);
	fail();
}
  1. if the error component is missing, the server will send an error response because of an now unhandled error. This can be avoided by adding a global error handler or an error boundary in a parent component.
  2. if you don't call fail(), it will hang forever

it's the second part I am not sure how it should behave right now, if fail()would be mandatory to call on the server. We lack documentation for that feature.

@LinusBorg LinusBorg added scope: ssr has workaround A workaround has been found to avoid the problem labels Apr 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has workaround A workaround has been found to avoid the problem scope: ssr
Projects
None yet
Development

No branches or pull requests

4 participants