Gatsby: Links not working after period of inactivity [tutorial]

[snirp]

I am following the tutorial, and I notice that the links are not being followed after a period of inactivity. The URL in the browser _does_ change after clicking a link, but only a blank page is loaded. Several javascript "cannot read ... of undefined" are displayed in the console.

Reloading does result in the correct page being displayed.

Steps to reproduce.

• Open a tutorial page, for instance: https://www.gatsbyjs.org/tutorial/part-five/
• Wait for 2 hours (exact time frame not known)
• Click any of the links on the page, for instance the next tutorial
• Observe that a blank page is displayed.

[KyleAMathews]

We should handle this better.

What's happening is when we redeploy the site (which we do all the time) then older versions of files are deleted. So if you open the site at v1 and then v2 is deployed, some of the files from v1 won't be available anymore. Which means that when you try to navigate to a page with now missing files, there'll be an error.

What we should do is a) detect errors loading a page resource then b) mark pages that depend on that page resource as "broken" and c) when the user tries to navigate to that page, we force a hard reload of the page so that the user moves to the current version.

[KyleAMathews]

This will be a lot easier to fix in Gatsby v2 (due to moving from require.ensure to dynamic imports which we can catch errors from loading) so I've added it to the v2 project.

[snirp]

That makes a lot of sense, should be it. Not the biggest issue in the world. Thanks for the quick reply.

[b4stien]

That's actually a pretty annoying issue and a showstopper for programatic navigation on our side. We also happen to redeploy pretty often (~ 20x times a day), and it's not acceptable for us to lose users at those points.

We'll be happy to run tests on Gatsby V2 and collaborate on a fix :)

[LoveYouFyi]

Related and slightly different problem. I was working through the documentation this week because I was going to build one web app using firestore and two eCommerce sites all with Gatsyb because of its fast loading time and other features. For me, problems became apparent when I had multiple tabs open for the gatsby docs. After leaving them open over night, when I came back to them, the pages were blank and had crashed. I tried to refresh them but they still only crashed and would not reload. I thought... is it React Router, or simply because it's a PWA? Unfortunately, despite the promise of very fast loading times, I cannot develop any production apps or sites with Gatsby with this problem. I will be looking at Gatsby v2 to see how things go with it.

However... what about similar problems that could creep up and render the app useless at any given time for unknown number of reasons? Perhaps a decent size React + PWA can be incredibly finicky to get right. I'm an early adopter of things that improve speed online. Got something in Beta that's the faster better next big thing, sure, I'll use that for my production app. But playing a long term paranoid game of preemptive whack-a-mole to keep your super-fast web app running and free of unknown problems is not appealing. Sounds like a web app built with Gatsby may require much more testing with many more different scenarios than alternative software solutions. I am all for putting out production apps using the latest and greatest. I am looking forward to things becoming more stable soon.

[KyleAMathews]

@nerikh hmmm sounds like a memory leak of some sort. I haven't encountered this before nor have we heard any bug reports. Gatsby does very little so it's very unlikely it's causing the trouble so odds are it's something specific to gatsbyjs.org. It's also potentially something in your browser env. Do other sites crash if you leave them open for long periods of times?

I'll leave a tab open on gatsbyjs.org and see if I can reproduce the issue.

[LoveYouFyi]

@KyleAMathews hey... no, this does not happen for any other sites, regardless of how long I keep the tabs open. I have had some tabs open for 3 days now, from multiple sites. This only happened on Gatsbyjs.org. And after it did happen, after spending the entire previous day working through the tutorials, I moved on without Gatsby. I would like to use Gatsby... Though now I've worked through PWA tutorials provided on developers.Google.com so I am able to achieve half of what appealed to me about Gatsby: PWA + Native App Experience in Android + iOS.

[dbrookes]

This is definitely happening, was just about to make an issue then stumbled on this one.

I've just upgraded a site from v1 which was fine to 2.0.0-beta.17 with offline plugin 2.0.0-beta.3.

This occurs after making a subsequent deployment and returning back to the homepage after you've previously visited and received a service worker, chunks that no longer exist are being requested and the error now causes the whole layout to disappear.

GET https://mysite.com/1-bf162cb7423673cacdbb.js 404 ()
GET https://mysite.com/0-76993c4ff512bafd19a7.js 404 ()
GET https://mysite.com/static/d/path---index-6a9-n94pbUC9Eck5kbqHmDHUXgv7M.json 404 
app-f8ea0306d4a95705047a.js:14 TypeError: Cannot read property 'pageContext' of undefined
GET https://mysite.com/5-cee5a4b9f8c0d5865477.js 404 ()
Uncaught (in promise) Error: Loading chunk 5 failed.
installingWorker ServiceWorker

The whole page goes blank, and a refresh resolves it. This is really infuriating on iOS where you have to quit the whole app and restart. Previously on v1 the page would reload when a new version of the site was deployed, but this no longer happens.

I also noticed that if you're on an internal page, and refresh, a new version of the service worker is installed even though a new version hasn't been released, this doesn't happen on the homepage.

Eg: head to https://www.gatsbyjs.com and make sure the worker installed, then go to https://www.gatsbyjs.com/how-it-works/ and reload the page, where you'll get a new SW every refresh.

[KyleAMathews]

Ah ok, so it's not a memory leak it's that Netlify deletes files from older builds and we don't catch when a resource 404s.

Ok, I remember now looking into this issue. Probably the safest thing then is to capture page resource load errors and then if the user tries to navigate to that page, we force a refresh. @pieh @m-allanson

[dbrookes]

Just to be clear, this isn't due to inactivity then clicking a link, it's simply returning to the site after a deployment, the same thing happens on the gatsbyjs.com site although you don't seem to lose the layout.

Looks like you deployed recently, two different machines that had previously visted:

Looks like you use Sentry, is this not happening for every returning visitor?

I guess if you don't have strict mime checking enabled, then it tries to execute the html it receives, trigging react to unmount the whole component tree.

[KyleAMathews]

Right, it's that the older version of the site is deleted by Netlify and we don't currently handle 404s (by forcing a refresh).

[KyleAMathews]

I'm actually working on revamping how we load page code/data bundles so can implement the fix i.e. catch dynamic import errors and force a refresh if the user tries to navigate to that page.

https://webpack.js.org/guides/code-splitting/#dynamic-imports

[KyleAMathews]

@pieh @davidbailey00 this is a good thing to test for w/ Cypress. Delete a page component bundle and make sure Gatsby handles it gracefully.

[davidbailey00]

@KyleAMathews This seems like something which should be handled with loadDirectlyOr404() when an error is caught, I can give this a go some time

[davidbailey00]

@KyleAMathews This seems like something which should be handled with loadDirectlyOr404() when an error is caught, I can give this a go some time

Actually on second thoughts, I think this is already fixed as part of my changes in #7355 - I haven't been able to cause it to error, unless I delete one of the files before loading the page for the first time, which of course is impossible in a production environment. Agreed we can still add tests for this.

edit: I think @DSchau was working on implementing some of my manual tests in Cypress, which include tests to prevent this from happening (by going offline, rather than deleting the files).

[chestozo]

This issue is still valid for 2.12.1 :(
Shell we reopen it?

[StuartStephens]

Still having this issue on gatsby 2.12.0 whenever I re-deploy on netlify.

[davidbailey00]

@chestozo @StuartStephens sure, please can you edit your build command to include the output of gatsby info and include that in a comment? This issue seems to be different depending on environment so it would be helpful for testing purposes.

[yoavniran]

just to chime in that im having the same issue after redeploy from Netlify. (Gatsby 2.13.72)
if page is open it will remain showing but nothing (like navigation) will work until I refresh the page...
Is there anything I can do on my end to remedy/workaround this or do we need a fix from Gatsby?

[chestozo]

@davidbailey00 hi David
not sure how it can help (because it seems to me that it is just a generate problem for statically generated websites) but here is my output:

$ ./node_modules/.bin/gatsby info

  System:
    OS: macOS 10.14.5
    CPU: x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 10.16.0 - ~/.nvm/versions/node/v10.16.0/bin/node
    Yarn: 1.16.0 - ~/.nvm/versions/node/v10.16.0/bin/yarn
    npm: 6.9.0 - ~/.nvm/versions/node/v10.16.0/bin/npm
  Languages:
    Python: 2.7.10 - /usr/bin/python
  Browsers:
    Chrome: 76.0.3809.132
    Safari: 12.1.1
  npmPackages:
    gatsby: ^2.13.64 => 2.13.64
    gatsby-image: ^2.2.8 => 2.2.8
    gatsby-link: ^2.2.5 => 2.2.5
    gatsby-plugin-google-tagmanager: ^2.1.5 => 2.1.5
    gatsby-plugin-lodash: ^3.0.5 => 3.1.2
    gatsby-plugin-manifest: ^2.2.5 => 2.2.5
    gatsby-plugin-react-helmet: ^3.1.3 => 3.1.3
    gatsby-plugin-remove-serviceworker: ^1.0.0 => 1.0.0
    gatsby-plugin-sitemap: ^2.2.6 => 2.2.6
    gatsby-plugin-styled-components: ^3.0.7 => 3.1.2
    gatsby-plugin-typescript: ^2.0.15 => 2.1.2
    gatsby-react-router-scroll: ^2.0.7 => 2.1.3
    gatsby-remark-images: ^3.1.11 => 3.1.11
    gatsby-source-filesystem: ^2.1.9 => 2.1.9
    gatsby-transformer-json: ^2.1.11 => 2.2.2
    gatsby-transformer-remark: ^2.6.14 => 2.6.1

So what happens in our case from my perspective is:

• we deploy a new website version to google cloud hosting
• when we do that - old version gets removed

Case 1: user who has opened website with older version

• he tries to navigate to some page
• a script for that page is loaded but it is not available anymore
• [result] nothing happens (actually a script load error in console)

Case 2: user navigates to a our root website address (lets say to example.com)

• website is loaded together with old cached scripts (cached during previous website visits)
• [result] older page version is displayed
• [result] some of the pages navigations result in script load errors together with failed navigations

So: do we need to do something special in our project to handle this navigation failures and reloading browser?
Or should this be handled by gatsby?

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[chestozo]

not good )

[dw2]

just to chime in that im having the same issue after redeploy from Netlify. (Gatsby 2.13.72)
if page is open it will remain showing but nothing (like navigation) will work until I refresh the page...
Is there anything I can do on my end to remedy/workaround this or do we need a fix from Gatsby?

I'm seeing the same thing using v2.15.28, also deployed with Netlify.

[gatsbot[bot]]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community!

[LekoArts]

Please try with the latest version of Gatsby and all packages.

[richhiggins]

to clarify, is this now handled by the latest version and so a non-issue?

[github-actions[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[github-actions[bot]]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.
Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community! 💪💜

[hugofabricio]

Hi, i have same problem in v 2.20.12

[karlhorky]

Yes, still having this issue with 2.22.20 (I would upgrade to 2.23.1, but versions after 2.22.20 broke MDX again, and #24813 hasn't been released yet).

[karlhorky]

@davidbailey00 was this bug actually ever addressed in a released version of Gatsby?

cc @LekoArts @KyleAMathews @pieh

[karlhorky]

If there's complexity with implementing a forced refresh / hard reload in the <Link /> component by default, a stopgap measure of having the ability to configure fallback or failure behavior of <Link /> components globally would probably be acceptable...

Eg. The ability for a user to specify an error callback function in gatsby-config.js when a link navigation fails for whatever reason.

[LekoArts]

Please open a new issue with a minimal reproduction if you're still experiencing this, the initial issue here was addressed and further comments didn't provide said reproduction.

[karlhorky]

Hmm... I understand the whole "being a maintainer is hard" argument, but just closing issues without even asking is not a great way to treat the Gatsby community, especially when there are multiple users saying that it is not fixed.

I would expect better - like even working with the users to guide them towards describing a valid new issue. Even better - I've seen some really good triage teams open one for them, using their feedback.

But yeah, I guess that can't be expected here. So I'll invest some time to try to open a new issue for everyone.

[karlhorky]

I've tried deploying two different Gatsby projects (1x normal JavaScript and 1x MDX) to Netlify now, and although they generate 404s during prefetching during hover, when the links have been clicked on, they go to the link provided in the href and load the HTML page normally.

I cannot reproduce the issue that I personally have been having on Render.com where the links don't work at all (but I believe this is a different issue - detailed below).

---

However, in doing a bit of research, it seems like others are having issues with the gatsby-plugin-offline plugin - this generates Link prefetching errors such as TypeError: Cannot read property 'map' of undefined as detailed in the original issue.

https://github.com/slorber/gatsby-plugin-react-native-web/issues/34#issuecomment-627743639

But then again, this could also just be unrelated.

@yoavniran @chestozo @dw2 @hugofabricio Does disabling the offline plugin help? Can you provide additional details regarding your errors? Eg. are there any exceptions in the JavaScript console?

If we can collectively come up with something that is reproducible, then we can open this new issue.

---

My error:

When I hover over <Link />s to trigger prefetch requests to /page-data/app-data.json and these requests take a very long time (or stay open as pending), the links do not fall back to the default behavior of just going to the href specified.

This is due to the call to loader.loadPage() in cache-dir/navigation.js -> navigate(), which never resolves and does not have a timeout associated with it.

I believe this is a bug and there should be a timeout for the prefetch to fall back to default link behavior.

[karlhorky]

Digging a bit deeper, it seems like there is some code in cache-dir/navigation.js -> navigate() that is written as if it should handle the cases described in this issue.

This code may be failing, which could be related to some of the failures seen in the thread above.

[karlhorky]

Ok, I've created an issue for my issue. Maybe it's related to what is being experienced by others here:

https://github.com/gatsbyjs/gatsby/issues/25330