404 page flashes and then the page becomes blank for pages that don't exist

[CodyRay]

Description

(I am using Gatsby v2)

When trying to load a page that doesn't exist, the 404 page flashes and then the page becomes blank.

#2223 is similar, but I think this is a different problem because render isn't being called for my Layout component.

I did some poking around and I believe that this happens because getResourcesForPathname is always called with location.pathname, so when PageRenderer is rendered none of the resources for the pages are loaded and it render's null. (I could be reading things wrong though)

Steps to reproduce

Go to: https://blissful-bassi-4d7d8c.netlify.com/something and observe the blank page

That website is just a copy of gatsby-starter-default v2

Expected result

The 404 page should be displayed

Actual result

A blank page is ultimately displayed

Environment

I set up a repro on netlify with the latest @next packages to reproduce:

    "gatsby": "^2.0.0-beta.98",
    "gatsby-plugin-manifest": "^2.0.2-beta.5",
    "gatsby-plugin-offline": "^2.0.0-beta.9",
    "gatsby-plugin-react-helmet": "^3.0.0-beta.4",

https://github.com/haroldhues/test-gatsby-starter-default-404/tree/master

(FYI gatsby info --clipboard failed on my computer (Windows 10) with an unhanded rejection...)

File contents (if changed)

gatsby-config.js: N/A
package.json: N/A
gatsby-node.js: N/A
gatsby-browser.js: N/A
gatsby-ssr.js: N/A

[cezarneaga]

could this be a netlify issue?

[afuh]

@cezarneaga I am experiencing the exact same "flashing 404" issue without Netlify.

After building for production, if I serve the /public folder (i.e gatsby serve) and I hit a 404, gatsby is not showing the 404 page.

mysite.com/someerror // Cannot GET /someerror

[cezarneaga]

Seeing that too. Will have a look where the bug is. Its a production build issue alone. In dev it brings the 404

[jkimbo]

We're seeing this issue too with a website hosted on S3 (https://www.zego.com). Going to a route that doesn't exist (e.g. https://www.zego.com/dsfds) shows the 404 page briefly before becoming blank.

[cezarneaga]

@jkimbo i can see the same in my repos.
error seems to be sourced to gatsby/cache-dir/production-app.js but after spending some time there couldn't figure it out. with 2.0.0-beta.61 it seems to work: https://startarium.netlify.com/404dss

could stem from the change to reach/router but...?

@KyleAMathews worked on reach/router but @pieh did some work on the gatsby/cache-dir/loader.js particularly fixing the redirects issue which seems to still be there somehow

[Chuloo]

thanks for the repro @haroldhues, got the same error as @afuh when I ran gatsby build on my local.
localhost:9000/jh displays Cannot GET /jh.

Clone @haroldhues repro.

[sorensenjg]

Just ran into this myself, hosting on AWS S3. Any news?

[BalachandraTejas]

Guess that's how the way it works in Gatsby website about Adding a 404 page.
"When developing, Gatsby adds a default 404 page that overrides your custom 404 page."

[colbyfayock]

i think i'm also seeing this on s3, or something similar. can confirm the 404 page is there by going to /404, which also throws an error. I started seeing this after #11524 was resolved, which i was first having issues with.

issues have been only happening on deploy. building locally via mac and upload to s3 works fine. build on deploy via linux with upload to s3, no luck. have been using freeze lock with yarn and have made sure there are no weird errors on deploy.

the weird thing is if I go to any valid route, I receive the static HTML to render the page at first, but then the following error is thrown, which prevents any page activity or redirects:

let me know if this seems different and I'll pop open a new issue.

Not sure if this helps at all or matters, but found it interesting. page-data looks like it's looking for /404/, but this page-data file has no response

then /404.html with a successful response

[dbsimeonov]

Any news on this one?

My stack is with Nuxt and has the following scenario:
/blog/:id

After getting an id that doesn't match my db -> redirects to 404 for half a second and after that returns /blog/ with empty content (the blog has content just through that blink from 404 it returns nothing).

Any ideas of how I can fix that - have it on multiple routes.

[Natansab]

Hey @cezarneaga it seems that the previous error you had is now fixed, congrats.
I have kind of the same error when visiting a specific webpage, for example /%E2%80%8E (https://www.startarium.ro/%E2%80%8E)
Do you know why this happens and how to fix it?

[JulioC]

I'm still having this issue with an Cloudfront + S3 deployment on gatsby@2.21.35: https://pushstart.com.br/this-page-doesnt-exists

I tried debugging it, but the flow looks similar to what @colbyfayock posted before.

[colbyfayock]

@JulioC not sure if this is the same situation - but we have to use a Lambda@Edge function to route the requests to the proper address with Cloudfront in cases where /path or /path/ doesn't work but /path/index.html works. Otherwise, you'll get pointed to the default root object or the error object which after loading will kick in the client-side routing

If that's the issue though, it's because AWS isn't routing to the right file unfortunately

[JulioC]

@JulioC not sure if this is the same situation - but we have to use a Lambda@Edge function to route the requests to the proper address with Cloudfront in cases where /path or /path/ doesn't work but /path/index.html works. Otherwise, you'll get pointed to the default root object or the error object which after loading will kick in the client-side routing

We are using a simple rule to catch 403 responses from S3 and return the /404/ page instead.

---

I've ended up finding the issue when looking through the files in our S3 bucket:there are both a /404/ and a /404.html/ folders there, which smelled like a problem. It turns out removing the /404.html/ folder solved the issue (I still don't see why).

Digging a little deeper, that folder is recreated on every build, because of the code snippet we copied from examples/using-i18n/gatsby-node.js.

The fix we used is skipping the delete/create process for the 404 folder:

exports.onCreatePage = ({ page, actions }) => {
  if (page.path.match(/404/)) {
    return;
  }

  // ...
};