next.js: Next 10.0.8 attempts to generate static error pages despite `_error` with `getInitialProps`

What version of Next.js are you using?

10.0.8

What version of Node.js are you using?

12.13.0

What browser are you using?

All

What operating system are you using?

macOS

How are you deploying your application?

Own infra

Describe the Bug

We have an _error component with getInitialProps (as does our _app component) and no /404 or /500 components, as we need dynamism on these routes for i18n, tracking, etc. Under 10.0.7, this correctly opted all error paths out of static optimization during build:

Warning: You have opted-out of Automatic Static Optimization due to `getInitialProps` in `pages/_app`. This does not opt-out pages with `getStaticProps`
Read more: https://err.sh/next.js/opt-out-auto-static-optimization

info  - Collecting page data  
Page                                           Size     First Load JS
┌ λ /                                          306 B           429 kB
├   /_app                                      0 B             296 kB
├ λ /404                                       308 B           429 kB
├ λ /login                                     309 B           429 kB
├ λ /not-found                                 309 B           429 kB
...etc

Under 10.0.8, next build attempts to erroneously generate static pages, which fails because they rely on dynamism (specifically data collected from our custom server and transported into Next via the req object):

Warning: You have opted-out of Automatic Static Optimization due to `getInitialProps` in `pages/_app`. This does not opt-out pages with `getStaticProps`
Read more: https://err.sh/next.js/opt-out-auto-static-optimization

info  - Collecting page data  
[  ==] info  - Generating static pages (0/3)
Error occurred prerendering page "/404". Read more: https://err.sh/next.js/prerender-error
...

Error occurred prerendering page "/404.html". Read more: https://err.sh/next.js/prerender-error
...

Error occurred prerendering page "/500". Read more: https://err.sh/next.js/prerender-error
...

info  - Generating static pages (3/3)

> Build error occurred
Error: Export encountered errors on following paths:
	/404
	/404.html
	/500

I’m guessing this was introduced alongside the new static /500 component introduction?

Expected Behavior

next build won’t attempt to generate static pages for 404/500 paths when _error has getInitialProps defined and no static 404 or 500 components are defined

To Reproduce

Attempt to build a next app with _error with getInitialProps defined and no 500 or 404 components

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 17
Comments: 16 (7 by maintainers)

Commits related to this issue

Ensure /404 is not exported during build un-necessarily (#22825) This ensures we don't export `/404` during the automatic static optimization during build when the `/404` isn't static and won't be us... — committed to vercel/next.js by ijjk 3 years ago
Update /500 page exporting when _error has custom GIP (#22887) This updates to not automatically export `/500` from `_error` if a custom `getInitialProps` is used since logic may be used inside of th... — committed to ijjk/next.js by ijjk 3 years ago
Roll back to next@10.0.7 to avoid vercel/next.js/issues/22815 — committed to zenflow/hasura-node-monolith-example by zenflow 3 years ago

Most upvoted comments

The latest commit pushed in 10.0.9-canary.1 fixes the 404 issue, but I still have a similar issue with respect to /500

Error occurred prerendering page "/500". Read more: https://err.sh/next.js/prerender-error
TypeError: res.redirect is not a function
    at Function.module.exports.1TCz.app_default.a.getInitialProps (/Users/prarabdhb*****/Projects/*****/build/server/pages/_app.js:9753:9)
    at Function._callee$ (/Users/prarabdhbharti/Projects/bharat11-web/node_modules/next-redux-wrapper/lib/index.js:183:44)
    at tryCatch (/Users/prarabdhbharti/Projects/bharat11-web/node_modules/regenerator-runtime/runtime.js:63:40)
    at Generator.invoke [as _invoke] (/Users/prarabdhbharti/Projects/bharat11-web/node_modules/regenerator-runtime/runtime.js:293:22)
    at Generator.next (/Users/prarabdhbharti/Projects/bharat11-web/node_modules/regenerator-runtime/runtime.js:118:21)
    at asyncGeneratorStep (/Users/prarabdhbharti/Projects/bharat11-web/node_modules/next-redux-wrapper/lib/index.js:18:103)
    at _next (/Users/prarabdhbharti/Projects/bharat11-web/node_modules/next-redux-wrapper/lib/index.js:20:194)
    at /Users/prarabdhbharti/Projects/bharat11-web/node_modules/next-redux-wrapper/lib/index.js:20:364
    at new Promise (<anonymous>)
    at Function.<anonymous> (/Users/prarabdhbharti/Projects/bharat11-web/node_modules/next-redux-wrapper/lib/index.js:20:97)

The response object in _app.js’s getInitialProps doesn’t contain redirect for some reason. Used to work fine with v10.0.7

prarabdhb on Mar 8, 2021

We have a custom server and it is responsible for:

processing the request and generating the correct i18n payload so that our strings can be in the correct language
periodically pulling our latest dynamic configuration settings from a remote and sending that into the app handler
other stuff based on request headers, filtering out bad requests, etc

All of the Express-to-Next transport is accomplished by appending data to the req object in Express land before sending things into the Next app handler. At runtime, this process is always guaranteed to happen safely and this is reflected in our non-nullable types upon entering Next land. We’re consciously avoiding any static generation because it does not support our requirements (i18n at the same routes for instance). From Next 5 when we started and through Next 10.0.7, this was achievable: basically we’re here for the SSR and have no need for SSG (in this particular app, we happily use SSG in other contexts).

I understand why we have this issue with the build changes in 10.0.8 - Next’s static build can’t possibly know about the details of our custom server - but I wouldn’t necessarily call this a bug, especially since Next explicitly supports custom servers. The errors are actually thrown in the _app code where we process our custom req additions and feed them into context providers. The _error code is actually pretty straightforward but relies on our i18n context, for instance. I realize that I could work around this particular bug by adding ? or | undefined to all of the relevant types and then do more fallback in _app (and/or its sub-components) at the relevant locations all to be able to generate assets that we don’t want and would probably add a post-build step to delete, but that would feel pretty bad.

It’s possible that we could transition some of this to an _app-based gSSP approach, but that’s not currently supported. Something like our dynamic configuration is basically only valid for its 15 minute window, so a statically generated version would be weird anyway. And I imagine that if _app supported gSSP, then that could again opt things out of SSG anyway.

I may have been too proscriptive in the initial bug description. Basically the problem is that we want to always avoid SSG for this app. That was previously possible through our current configuration. Supporting that combination going forward would be one solution. Another would be simply exposing a configuration flag that explicitly disables all SSG, which would probably be easier to support long-term without regressions. If I had to resort to using patch-package to eliminate this behavior for us on my own, this is certainly the path I would take (making the SSG availability always false somehow).

merrywhether on Mar 6, 2021

I followed the with-sentry example in this repo and it is now failing to build due to the _error.jsx file.

jondcallahan on Mar 6, 2021

Still seems to be somewhat of an issue at least in v10.0.9-canary.6. Except it just says [ =] info - Generating static pages (0/0) and never finishes

tm1000 on Mar 11, 2021

This should be updated in v10.0.9-canary.3 of Next.js, please update and give it a try!

I upgraded to this version and now everything is working as it should. My task will not need to be blocked, thank you very much!

matheusalcuri on Mar 9, 2021

This should be updated in v10.0.9-canary.3 of Next.js, please update and give it a try!

ijjk on Mar 9, 2021