Next.js: Error component rendered 2 times when server rendering in production

[timneutkens]

Expected Behavior

1 error component is rendered

Current Behavior

2 error components are rendered below eachother. 1 through SSR and 1 through client side rendering.

Steps to Reproduce (for bugs)

import Link from 'next/link'

export default class extends React.Component {
  static async getInitialProps() {
   // Just throw an error in getInitialProps
    throw new Error('test');
  }
  render() {
    return (
      <div>
        <h1>Hello world</h1>
      </div>
    )
  }
}

Context

Issue can be seen here: https://create-next-example-app-olyuogqcxe.now.sh/ (deployment with the above code). Scroll down cause the component itself is screen filling 😅

@harshmaur surfaced this.

Your Environment

| Tech | Version |
|---------|---------|
| next | 2.x+ (so beta too) |
| mode | production |

[stevegeek]

@timneutkens I think I have run into this too. Any update on a fix?

Also I am wondering why here https://github.com/zeit/next.js/blob/v3-beta/server/render.js#L223 the error object in production is converted into a simply object containing only a message regardless of the error , thus the client sees this 'err' object. However if my custom error page renders differently depending on the error and say its status code this line masks the true error and makes everything into an unhandled exception.

For example if I simply want to render a 404 page for a resource that doesnt exist, in my application code i can throw an Error containing a status code to indicate this and handle that in _error page, the server will render correctly as it has the 'true' Error object, however, on the client the serialised object will be this masked object.

What is the recommended way to do error handling in next.js with a custom server?

If I handle the error at the page rendering level (wrap the getInitialProps or render method in a try/catch then render a '404 Not Found' page , what can I then do to make the response from the server have a 404 status code, as in this case for all intents and purposes the page has rendered correctly and results in a 200 status code. https://github.com/zeit/next.js/blob/v3-beta/server/render.js#L193.

(Edit: actually I just realised in the above case I can set res.statusCode inside getInitialProps when on the server)

Thanks for any advice!

[coluccini]

@timneutkens, the example is no longer rendering the error page 2 times, did you solved it? Cause I'm seeing this issue as well and, cause you can only see it in prod, I'm having hard times to find the root issue…

[kochis]

We are also seeing this behavior whenever an un-caught exception is thrown on the server (404's behave as expected). The server renders the error page as expected, but the client _also_ renders the error page.

My guess at what is happening, is that the server error is somehow being surfaced to the client, which causes the next handling of client-runtime errors to also be rendered (the one that gets rendered to __next-error), which is why you see it below the original error.

Does __next-error assume the content in __next is always empty? Because I think that is not the case when the error page is rendered on the server.

I've created an example that replicates the issue here: https://github.com/kochis/next.js/tree/duplicate-error-example/examples/duplicate-error-pages

If there is also a more appropriate way to handle the error to avoid this, any help would be appreciated.

[kochis]

I believe this was introduced in https://github.com/zeit/next.js/pull/1800

And the problem code is here:
https://github.com/zeit/next.js/blob/v3-beta/server/render.js#L114

If there is an error on the server, it's sent to the client through the err prop, which is what the client is using to determine whether it should render the error page: https://github.com/zeit/next.js/blob/master/client/index.js#L96

So it seems like any uncaught exception will render both server & client error pages. I'm not sure what the correct behavior for this _should_ be, but one solution I could think of would be to add .ignore to the error object created server-side.

[lock[bot]]

This thread has been automatically locked because it has not had recent activity. Please open a new issue for related bugs and link to relevant comments in this thread.