You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I verified that the issue exists in the latest Next.js canary release
Provide environment information
Operating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 21.6.0: Sat Jun 18 17:05:47 PDT 2022; root:xnu-8020.140.41~1/RELEASE_ARM64_T8101
Binaries:
Node: 16.14.0
npm: 8.3.1
Yarn: 1.22.15
pnpm: 6.32.11
Relevant packages:
next: 12.2.5-canary.1
eslint-config-next: 12.2.4
react: 18.2.0
react-dom: 18.2.0
What browser are you using? (if relevant)
Chromium 104.0.5112.81 (Official Build) (arm64)
How are you deploying your application? (if relevant)
N/A
Describe the Bug
For the following simplified application structure:
pages/
index.js (with getServerSideProps)
_app.js
_error.js (with getServerSideProps)
in production, if there is an error within a page's getServerSideProps call (e.g. index.js), the app will fallback to rendering the _error.js page.
Assuming that the _error.js file successfully calls getServerSideProps and renders the error component, that content will be flushed to the browser. (no issue here yet)
When that error page is hydrated on the client, Next logs that there was a 500 error on the server (because of the error in index.js's getServerSideProps) and attempts to render the component.
Note: At this point I'm not exactly sure why it starts to go into a loop, my hunch is that the props from the server don't contain an err field that is inspected (it seems to live higher up in the initial data sent from the server), causing the framework to go down the path of calling getInitialProps
Through that rendering process, Next tries to call getInitialProps on either the _app component or the page it was rendering (in our case _error), if neither exist it returns an empty object.
This empty object then breaks our assumption within _app where we expect to have the props returned from either index.js's or _error.js's getServerSideProps, so when that data isn't there it throws.
The loop then continues here because the top level error boundary (Container component in next's lib/client/index.tsx file) attempts to retry rendering the fallback page, re-entering the error loop above.
Expected Behavior
If an error occurs during hydration, try to re-render only a limited number of times (that could be only trying to render it once, or maybe not even trying to re-render the page).
hamlim
changed the title
Potential for infinite error loop during clientside hydration
Potential for infinite error loop during client-side hydration
Aug 10, 2022
This seems to be a regression introduced in 12.2.1. In 12.2.0 I don't encounter the infinite loop, and I'm able to trigger the infinite loop in 12.2.1. This is infinite loop no longer occurs in 12.2.5, though this version yields a behavior different than experienced in 12.2.0 and previous next versions: #39467 (comment)
The fix that closed this issue is only available in v12.2.5, it'd be good to verify with the latest canary as we have a regression test for this now which is currently passing.
This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.
Verify canary release
Provide environment information
What browser are you using? (if relevant)
Chromium 104.0.5112.81 (Official Build) (arm64)
How are you deploying your application? (if relevant)
N/A
Describe the Bug
For the following simplified application structure:
pages/
index.js
(with getServerSideProps)_app.js
_error.js
(with getServerSideProps)in production, if there is an error within a page's
getServerSideProps
call (e.g.index.js
), the app will fallback to rendering the_error.js
page.Assuming that the
_error.js
file successfully callsgetServerSideProps
and renders the error component, that content will be flushed to the browser. (no issue here yet)When that error page is hydrated on the client, Next logs that there was a 500 error on the server (because of the error in
index.js
'sgetServerSideProps
) and attempts to render the component.Through that rendering process, Next tries to call
getInitialProps
on either the_app
component or the page it was rendering (in our case_error
), if neither exist it returns an empty object.This empty object then breaks our assumption within
_app
where we expect to have the props returned from eitherindex.js
's or_error.js
'sgetServerSideProps
, so when that data isn't there it throws.The loop then continues here because the top level error boundary (
Container
component in next's lib/client/index.tsx file) attempts to retry rendering the fallback page, re-entering the error loop above.Expected Behavior
If an error occurs during hydration, try to re-render only a limited number of times (that could be only trying to render it once, or maybe not even trying to re-render the page).
Link to reproduction
https://github.com/hamlim/next-error-clientside-loop
To Reproduce
yarn install
yarn build
yarn start
localhost:3000
and open dev tools to see the loop of errors happeningThe text was updated successfully, but these errors were encountered: