Potential for infinite error loop during client-side hydration

[hamlim]

Verify canary release

• 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).

Link to reproduction

https://github.com/hamlim/next-error-clientside-loop

To Reproduce

• Clone the above repo
• Run yarn install
• Run yarn build
• Run yarn start
• Visit localhost:3000 and open dev tools to see the loop of errors happening

[ijjk]

Hi, good catch! I opened a PR to ensure we can properly handle this case here #39467

[tatethurston]

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)

[ijjk]

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.

[github-actions]

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.