SSG doesn't work for 404 error pages in Vercel environment when using getInitialProps on _app

[vajajak]

Bug report

SSG doesn't work for 404 error pages in Vercel environment when using getInitialProps on _app

Describe the bug

Since there is still no support for getStaticProps on _app, I'm forced to keep using getInitialProps on _app to fetch common data for shared components (header, footer, seo, ...). Up until this point, I had no problems with this approach since I'm using getStaticProps to fetch data in all of my pages, and this does not opt-out of SSG. So only downside is that my website cannot use automatic static optimization.

However, today I noticed that when I go to page that does not exists and I get redirected to a 404 error page, I see changes in header that were made after the build. What is even more strange is that even when I clear all of my cache, on all subsequent requests to this page, changes in header are no longer reflected. But they still are reflected on 404 pages that i didn't access yet (but also only on the first access). The way it works closely resembles how Incremental Static Generation works.

It is important to note that I'm returning an empty getStaticProps in this page also, since I want the 404 error page to be also able to utilize SSG (since I'm using getInitialProps on _app and this is not automatic). (See screenshots below)

When seeing the build log, I get a full dot next to the 404 page meaning the page is statically pre-generated.

When running npm run build and npm run start on localhost, this issue does not occur. Not even when exporting to serverless environment (target: 'serverless' in next.config). But once I push the project to Vercel, the problem arises. From what I have discovered during my research, this bug is exclusive to Vercel environment.

To Reproduce

1. Run getInitialProps on _app
2. Create a custom 404 error page with empty getStaticProps
3. Push to Vercel
4. Go to a page that does not exist

Expected behavior

I expect the page to be statically generated since that is what I'm seeing from the build output.

Screenshots

Custom 404:

Build output:

System information

• OS: macOS 11.0.1
• Browser: Chrome 87.0.4280.88
• Version of Next.js: 10.0.3
• Version of Node.js: 12.14.1
• Deployment: Vercel

Additional context

During my research I also discovered that getStaticProps is not passing data to custom 404 component. I don't know if that's intentional. I didn't find it mentioned anywhere in the documentation though.

[vajajak]

Update on this issue:
Today I noticed that 404 pages are no longer even loading. In Vercel environment, I get a 502 Bad Gateway error with CODE: NO_RESPONSE_FROM_FUNCTION, instead of a 404 page. I see this behaviour throughout all of my past deployments.

[vajajak]

Additional context:
Next.js client-side router object is showing property isSsr: true.

[zenflow]

There seem to be a lot of issues when using SSG (getStaticProps) with custom 404 pages in general (not only using getInitialProps in _app). @vajajak I might suggest editing the title of this issue to reflect that.

In my case I'm not using getInitialProps in _app. I'm just trying to use getStaticProps with my custom 404 page (pages/404.tsx) to get some data that is used in the layout (e.g. company address in footer), and here is what I found:

1. Looking at the output from next build, the icon next to the /404 page indicates "Static" (uses no initial props) rather than SSG (uses getStaticProps). Not an issue itself, but it indicates something is not right. (This happens locally and when building on Vercel.)
2. When the app is running (in production mode) on Vercel, the /404 page's getStaticProps gets called when the 404 page is accessed. (Note: I found this out with a simple logging experiment.) I would expect it to behave like the all other pages, which don't have their getStaticProps called during runtime in production (unless preview mode is enabled, or using revalidate). Strangely, this issue doesn't apply when the app is running in production mode locally.. in this case everything works fine and the /404 page's getStaticProps is not called unexpectedly.

Number 2 (above) is a real issue for me because my getStaticProps function tries to read a file from the project file tree (e.g. content/global.json).. I guess Vercel doesn't include all project files in a deployment, so that file isn't present, so we get an ENOENT error when trying to read it, so we get Vercel's "NO_RESPONSE_FROM_FUNCTION" error page (looking exactly like the one above #19849 (comment))

[zenflow]

@vajajak I'm curious what error is being logged if you click "check the logs" on the NO_RESPONSE_FROM_FUNCTION error page...

[zenflow]

After working around the file read error, I found that the 404 page getStaticProps gets called (at runtime in production) each time the page is accessed if it keeps erroring. If it doesn't error, the result seems to be cached. Still it should be treated like all the getStaticProps, and not be called at runtime in production unless preview mode is enabled, or using revalidate.

[vajajak]

Hey @zenflow, thanks for commenting on my issue. I'm glad I'm not the only one who's experiencing such an issue.
Regarding your points:

1. I tried removing getInitialProps from _app. After doing that, I can confirm that the build output is showing "Static" (uses no initial props) instead of SSG (uses getStaticProps), even though the getStaticProps is still present on 404, but still behaves very strange.
2. From what i have discovered seeing the build output from Vercel dashboard, I think that Vercel doesn't keep around the files that aren't necessary to run the app. Under normal circumstances, getStaticProps gets run only in build step and contents of the file you're referring to are fetched in this step (and preserved in form of JSON + HTML). That source file is thus no longer needed and isn't included in the build output. Due to this issue however, getStaticProps is also ran at runtime when this file is no longer around. This is where I think your problem is coming from.

• To answer your question about the logs. There are none. Naturally the logs were the first place that i headed to, but to my surprise, there really isn't a single one. I tried deploying again, having the logs page open and running into the issue but still, I didn't catch a single log there. I don't think I'm getting an ENOENT error as you though, as I'm fetching the data from an external source (CMS) which should be available at all times.
  

[zenflow]

Due to this issue however, getStaticProps is also ran at runtime when this file is no longer around. This is where I think your problem is coming from.

@vajajak Yup, that's exactly it. I worked around this issue by using dynamic import (e.g. await import('../content/global.json'), instead of reading the file from the filesystem, so that the file is bundled in at build-time. This isn't really ideal though since dynamic imports have limitations when it comes to dynamic/variable module identifiers (e.g. import('../content/${file}')) and I can't use my abstraction for loading content files (which involves more than just loading a local json file).

To answer your question about the logs. There are none.

Hmm.. that's strange. You are aware that for the error log to be displayed, the "Realtime Logs" screen has to be open when the error is generated, right? If you get an error and then open up the Realtime Logs, you won't see that past error.
Also, maybe make sure you are looking at the Realtime Logs for the most recent deployment? I made the mistake a few times where I was accidentally looking at the logs for an old deployment.

[vajajak]

@zenflow Yup, I am aware that the logs page needs to be open. It's possible I accidentaly looked at a different deployment. I'm still not really sure what is causing the NO_RESPONSE_FROM_FUNCTION errors so I'm not sure how to reproduce it again right now (sometimes it just runs with this strange behavior described in my original bug report and sometimes returns the error). It's getting really late here so I'll try to reproduce it tomorrow and seek the logs again, and I'll let you know.

[vajajak]

Hey @zenflow and sorry for the late response.
I wasn't able to reproduce the issue several days now, until today.
Here's the log:

I'm afraid I'm none the wiser though. From what I can see from the log, the issue comes from the 404 page itself. The _site property is a result from query to my cms, which gets run in getInitialProps. Seeing the real-time logs, it's obvious this getInitialProps gets run again on the request, which itself is a problem. However, I'm not sure why I'm getting the type error since the query should run just fine even in runtime on server.
Any ideas?

[zenflow]

Any ideas?

@vajajak Hmm without knowing the details of your project, I don't really have any guesses as to why your cms query behaves differently/strangely in this case.
I would add some logging code and deploy (maybe to a dummy deployment) to further debug the code.. e.g. print out any arguments/parameters to the cms query, print out the full result of the query (maybe it has an error message to give you a clue as to what's wrong).

[zenflow]

@vajajak Since we have narrowed in on the issue a little more, maybe the title of this issue should be updated, if only to get the proper attention?

• instead of "doesn't work" we can say what's actually going wrong and causing all the symptoms: "getStaticProps" is called at runtime (when not using preview mode or revalidate)
• we can remove the "when using getInitialProps on _app" bit because we know the issue exhibits itself without this condition

[ijjk]

Hi, this should now be updated to only run getStaticProps with /404.js at build time instead of once per-path during runtime unless you are leveraging revalidate in /404.js, please re-deploy your application and give it a try!

[vajajak]

Hey, @ijjk.
I appreciate your time you spent fixing this issue, however I'm still experiencing the same problem.
I did re-deploy my app, but the issue still persists. I'm currently on next.js 10.0.4.
Perhaps there's a problem with next.js itself?
Please let me know if there's anything I might be doing wrong.

[ijjk]

@vajajak can you provide a link to a repo/deployment where this is still occurring? If you are using revalidate in getStaticProps for /404.js then it is expected to still be called at runtime.

[vajajak]

@ijjk Here you go: https://zsjaklysa-27h00ad7a.vercel.app/_src.
I'm not using ISR (revalidate) at all in my app.
Thanks in advance.

[kmkr]

We've been struggling with the same issue and I also get these errors as soon as I include a getStaticProps function. I don't use revalidate on the 404 page either. So here's one more example in case you need, @ijjk https://vercel.com/otovo/storefront/9bla49ib6

[ijjk]

Thanks for the repo with the reproduction, I tracked this down and opened a follow-up PR here that should address the remaining aspect of this. I will update here when this is published

[vajajak]

@ijjk The PR seems to be merged now and the issue has been closed once again. Yet, I'm still getting the same issue.

To give a little more insight into what I'm actually doing to test this and how I have discovered this issue:

•  I Re-deploy the app with testing navigation item set to invisible in CMS. This item is named Testovaci strankaaaa.
• After the build I set the item to visible in CMS and navigate to a 404 page
• 404 error page pulls the data from CMS at runtime and therefore the Testovaci strankaaaa item becomes visible in navigation on this specific 404
• Result for this specific 'asPath' is cached and creates inconsistencies in items that are being displayed in navigation. Different versions of navigations can get cached even for different 404 pages.

You can actually try this yourself in my example. Again, this is the latest version: https://zsjaklysa-8bk643bqs.vercel.app/_src

1. Navigate to /skola/zakladni informace -- This is a SSG page (Testovaci strankaaaa - which is the first item in the navigation, is not visible here)
2. Now navigate to /skola/parlament -- (404 page) As you can see, Testovaci strankaaaa is now visible in menu and will be there until I re-deploy my app with this item set to invisible in my CMS.
3. Next navigate to /skola/vyberova-rizeni, which is another 404 page -- Here, the Testovaci strankaaaa is yet again not visible since I have hidden it again in my CMS before visiting this page. This is to demonstrate that different asPaths (404 pages) might be frozen at different states.

Thank you for your effort, I hope this gets resolved soon :)

[ijjk]

@vajajak the PR isn't available instantly when merged, it needs to be published to stable before it's available. I said I'd update here when it's available as the PR being merged doesn't mean it's available.

I just published this change so it should now be available

[vajajak]

@ijjk Got it. I apologize for my impatience :).
Can confirm it's now working as expected.
Thanks a lot for the fix. Keep up the great work 👍

[kmkr]

Great to hear that it works better. It unfortunately don't work for me, same error in the Vercel build logs. I tried the "Rebuild" button and I also tried to force a new build by re-pushing the commit.

Here's the latest failing build: https://vercel.com/otovo/storefront/8gqzoyv2j

Something I miss, @ijjk ?

[ijjk]

@kmkr this issue isn't related to a build-time error, this prevents the 404 getStaticProps from being called at runtime unexpectedly. Can you provide a repo with a minimal reproduction on a separate issue for the build-time error you are encountering?

[zenflow]

@ijjk Thanks for fixing this!

[kmkr]

@kmkr this issue isn't related to a build-time error, this prevents the 404 getStaticProps from being called at runtime unexpectedly.

Ok. I must have misunderstood the thread, sorry. This change consistently triggers the failing build:

And the logs don't help me much:

14:49:19.381 | Unhandled error during request: false
-- | --
14:49:19.381 | Failed call /_error subroutine, continuing to crash function: false
14:49:19.381 | Error occurred prerendering page "/404.html". Read more: https://err.sh/next.js/prerender-error
14:49:19.381 | undefined
14:49:19.382 | Unhandled error during request: false
14:49:19.382 | Failed call /_error subroutine, continuing to crash function: false
14:49:19.382 | Error occurred prerendering page "/404". Read more: https://err.sh/next.js/prerender-error
14:49:19.382 | undefined
14:49:19.444 | info  - Generating static pages (320/320)
14:49:19.444 | > Build error occurred
14:49:19.447 | Error: Export encountered errors on following paths:
14:49:19.447 | /404
14:49:19.447 | /404.html
14:49:19.447 | at exportApp (/vercel/workpath0/storefront/node_modules/next/dist/export/index.js:30:1103)
14:49:19.448 | at processTicksAndRejections (internal/process/task_queues.js:97:5)
14:49:19.448 | at async /vercel/workpath0/storefront/node_modules/next/dist/build/index.js:39:69
14:49:19.448 | at async /vercel/workpath0/storefront/node_modules/next/dist/build/tracer.js:1:525
14:49:19.507 | error Command failed with exit code 1.
14:49:19.508 | info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
14:49:19.517 | Error: Command "yarn run build" exited with 1
14:49:22.288 | Done with "package.json"

Can you provide a repo with a minimal reproduction on a separate issue for the build-time error you are encountering?

I'll try to work on that and will let you know if/when I have something.

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.