Client only routes - Query not run warning

[magicspon]

Description

I'm seeing the following errors and warnings for pages that are only rendered on the client. They are not using any queries, just plain ole react components fetching data from a rest api.

Warning in the terminal:

Error loading a result for the page query in "/app/overview". Query was not run and no cached result was found.
Page not found /app/overview

In the Browser after build:

prefetch.js:33 GET http://MYDOMAIN/page-data/app/faqs/page-data.json net::ERR_ABORTED 404 (Not Found)

@LekoArts is also seeing this issue, which you can see here:
https://tmdb.lekoarts.de/

Steps to reproduce

I've tried to replicate the issue with the client-only-routes example. Alas I could not reproduce the error.

Expected result

No warnings or errors in the browser.

What should happen?

As above, no errors or warnings.

What happened.

The errors described above

Environment

System:
OS: macOS 10.14.5
CPU: (8) x64 Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
Shell: 5.3 - /bin/zsh
Binaries:
Node: 12.6.0 - ~/.nvm/versions/node/v12.6.0/bin/node
Yarn: 1.16.0 - /usr/local/bin/yarn
npm: 6.9.0 - ~/.nvm/versions/node/v12.6.0/bin/npm
Languages:
Python: 2.7.10 - /usr/bin/python
Browsers:
Chrome: 75.0.3770.100
Firefox: 67.0.4
Safari: 12.1.1
npmPackages:
gatsby: ^2.13.2 => 2.13.2
gatsby-cli: ^2.7.7 => 2.7.7
gatsby-plugin-create-client-paths: ^2.1.1 => 2.1.1
gatsby-plugin-postcss: ^2.1.0 => 2.1.0
gatsby-plugin-react-helmet: ^3.1.0 => 3.1.0

[freiksenet]

Thanks, we are investigating this!

[aldegoeij]

+1

See #13197 as per #15401 (comment)

Duplicate of #15401

[wardpeet]

Closing as duplicate

[colbyfayock]

@wardpeet #15401 is closed and there's a bit of discussion over there still - should this issue be reopened to investigate this?

[colbyfayock]

hey folks, just wanted to follow up. the console errors are killin us :)
confirming still an issue on 2.13.39

[colbyfayock]

Seems a few others are having similar issues.

@himynameistimli:

I also seem to have the issue @colbyfayock describes above, but only for dynamic url client paths. For instance, my auth-required dashboard page works without any errors, but any dynamic url client paths gives console errors on dev, 404s on prod (running gatsby v2.13.32).

Another funny thing is that on another gatsby app that we run (running gatsby v2.7.1) I get 304 errors instead of 404 errors on production for dynamic url client paths.

@eknowles

im getting this issue described above on 2.13.28

[TheHalcyonSavant]

Same here. examples/client-only-paths is working fine, but with some errors in dev mode.
package.json:

{
  "name": "gatsby-example-client-only-paths",
  "dependencies": {
    "gatsby": "^2.13.45",
    ...
  },
  ...

gatsby develop console:

...
i ｢wdm｣: Compiled successfully.
Error loading a result for the page query in "/404.html". Query was not run and no cached result was found.
Page not found /404.html
Error loading a result for the page query in "/page/2". Query was not run and no cached result was found.
Page not found /page/2
Error loading a result for the page query in "/page/3". Query was not run and no cached result was found.
Page not found /page/3
Error loading a result for the page query in "/page/4". Query was not run and no cached result was found.
Page not found /page/4

[wardpeet]

Does #16220 fixes your issue?

[TheHalcyonSavant]

@wardpeet I can't confirm, I haven't collaborated to gatsby before. I don't know how to test easily gatsby-example-client-only-paths with the latest unpublished gatsby commit 73d15b0.

So far, I've tried to run yarn in gatsby/packages/gatsby and copied the dist in gatsby/examples/client-only-paths/node_modules/gatsby, but it fails. Please write If you know how to test this, I couldn't find doc for these scenarios.

[colbyfayock]

@wardpeet I'm still getting the errors on 2.13.45

Messages in the terminal when running develop...

Error loading a result for the page query in "[path]". Query was not run and no cached result was found.

On deploy...

[TheHalcyonSavant]

@wardpeet here are my results with the latest version:
package.json:

{
  "name": "gatsby-example-client-only-paths",
  "dependencies": {
    "gatsby": "^2.13.46",
    ...
  },
  ...
}

gatsby develop console:

...
i ｢wdm｣: Compiled successfully.
Page not found /404.html
Page not found /page/2
Page not found /page/3
Page not found /page/4

As you can see the line Error loading a result for the page query ... is gone but still Page not found is displayed.
gatsby build is working fine in gatsby-example-client-only-paths

[colbyfayock]

@wardpeet looks like i jumped the gun and missed 46 - confirming I'm seeing the same as @TheHalcyonSavant

Looks like I'm getting 2 different types of 404 on deploy...

[wardpeet]

I created a PR for to fix it. We won't be able to fix the not-found xhr requests as it's by design.

I'll see if I can create a plugin to disable this behaviour if you really want to. (#no-promises)

[colbyfayock]

@wardpeet curious about the intent of it being by design if we intentionally set them as client only routes within the configuration. isn't that part of the point, to distinguish them as unavailable?

if it should be a plugin, could this be a setting that gets applied to https://www.gatsbyjs.org/packages/gatsby-plugin-create-client-paths/ ?

[wardpeet]

Oh sorry, we have answered it in another thread.

#16097 (comment)

Trying to fetch page-data.json files is by design. Gatsby no longer have central manifest of available pages - if you are interested in why - please check gatsbyjs.org/blog/2019-06-12-performance-improvements-for-large-sites

Because Gatsby no longer have central pages manifest, it means that Gatsby will have to "blindly" check for metadata - which means there will be requests for metadata that end up being 404 in case of client side routes.

Does this cause issues other than just showing errors in console? I'm not sure if we can totally silence those errors and this is just what browsers will always do in case some request "fails" (because we do have handling on what to do if page-data.json is 404ing)

A little bit more context why we do this.

If we don't do the page-data check for the current page we'll bring back #15101.

Consider the following routes

[
  {
    "path": "/app/dashboard",
    "matchPath": "/app/*"
  },
  {
    "path": "/app/login",
  },
]

With that configuration, we won't be able to load /app/login as it's part of the matchPath logic. We will simply ignore the page and fallback to whatever is inside /app/*. The change to fix this behaviour was introduced in
#15762

A solution we could add is to save all paths that are inside a matchPath also into the matchPath.json so we know about all routes. This might bring back the page-manifest performance problem for site that heavily uses this behaviour.

Matchpath will look like

[
  {
    "path": "/app/dashboard",
    "matchPath": "/app/*"
  },
  {
    "path": "/app/login",
    "matchPath": "/app/login"
  },
]

[colbyfayock]

makes sense, thanks for the info.

whether or not that solution, is the plan definitely to address this in one form or another? i would have to imagine client paths are a common use case all around, especially given if I'm not mistaken, Gatsby is trying to position itself as an all around app solution rather than just a static site generator. receiving a bunch of 404's in a dynamic application doesn't seem like something to just ignore

[wardpeet]

@colbyfayock what problem do you see with 404s? Users won't see those 404s and it won't change their experience on your site.

[colbyfayock]

@wardpeet well, this is my 2c...

For one, it seems like it's an acknowledged problem where the known solution would break something else, meaning the "won't fix" is just that there's not currently a known valid solution. I mean I get it, and thats a totally valid reason for not doing the fix that you know of, so that it wont break other things, but i dont think that means it should be shrugged off as "how it is". it's not a normal side effect of an application. clearly other people see it as a problem too hence the commenting 🤷‍♀️

Does this get collected with error tracking integrations such as Sentry? I can't speak towards whether it does or not (looking to integrate a tool like this soon), but if it does, that's just adding lots of unnecessary logs for folk's logging, where in the logging world, that means more 💸

Additionally, it just generally clogs up the console in the browser making it more difficult to debug real errors, being able to tell what's real or broken. We use this feature (and I'm sure we're not alone) to handle client side dynamically generated routes from search results, meaning when the results come back, it's a ton of 404 spam in the console.

Agreed it may not be visible to the user, but it's still creating additional network traffic (though small for each) and using resources that aren't needed to make and handle that request. speaking without evidence, it may be more noticeable on slower devices with poor internet connectivity

That all said, I'd be curious to hear if anyone else has any thoughts.

Thanks for hearing me out :)

[TheHalcyonSavant]

@colbyfayock what problem do you see with 404s? Users won't see those 404s and it won't change their experience on your site.

Developers are considered users to Gatsby, and developer experience is impaired here, having to spend time understanding errors that don't make sense is a huge waste. The more developers read these errors and the more unnecessary time they spend researching github, the more embarrassing this argument is going to get.

[karldanninger]

The latest version of Gatsby (2.13.50) removes the warning, BUT there is still a printed line in the console "Page not found /things/123abc456xyz"

[ghost]

@karldanninger I have the same issue.

I just updated to Gatsby (2.13.50) from 2.13.45.

My issue right before I updated was that I had the warning: "Error loading a result for the page query in "/app/my-page". Query was not run and no cached result was found.
Page not found /app/my-page".

Also, before updating, if I routed with "navigate('/app/my-page')" then I would see a flash of the 404 page (in production, not dev).

So, now that I have updated to Gatsby 2.13.50, the 404 page flash seems to have been fixed but I still get the "Page not found /app/my-page" warning.

Edit: even after updating to Gatsby 2.13.50, the 404 page flash still appears when I click refresh in the browser. I'm using the guide from Gatsby here: https://www.gatsbyjs.org/tutorial/authentication-tutorial/

[karldanninger]

@break-paradigm I've encountered the flashing 404 thing myself. Doing this solved it for me #5329 (comment)

[ghost]

@karldanninger Thanks!

I'll def test that out.

For now, I did fix the 404 flash. I'm using Netlify and I didn't install the gatsby-plugin-netlify add-on that basically fixes redirects under the hood.

After that the 404 flash appears to be solved.

[kilburn]

@wardpeet:

@colbyfayock what problem do you see with 404s? Users won't see those 404s and it won't change their experience on your site.

1. They clog your logs, making analyzing actual 404's harder
2. They may trip crawlers (think google webmaster tools) into thinking you have many 404 errors (important when you are doing a site for another company and they get to see reports showing those errors)
3. They cost requests and bytes that you have to pay for
4. The requests for page-data/client-path/something/page-data.js, page-data/404.html/page-data.json and page-data/client-path/page-data.js are sequential, meaning that on high-latency connections people now has to between 1 (for the something part) and 3 (for all 3 parts) round-trips to get their page, instead of between 1 (for the client-path) and 0. Note: there is no prefetching when you navigate to some client url (which should be fine to do for whatever reason we need to).
5. They trip developers into thinking they are doing something wrong (it is a waste of developer time)

I understand you cannot solve this generally without going back to full-site manifests (which you understandably don't want to do) or breaking mixed client/static URLs.

However, many of us would be able to solve it for our particular cases if you give us some kind of "escape hatch". In our case, we are using a routing scheme, meaning that we have just ~60 url patterns (that end up generating several thousand pages). We load those patterns in all pages because reasons, meaning that we can very easily verify if some url is a client path or a static path.

Here are two alternatives that would allow us to solve this issue:

1. Just add a browser api isClientPath(path: string): boolean that we can implement, and skip the fetching if you get true from there. This should be easy to implement and wouldn't complicate the logic much on gatsby's side.

2. Add a new page property pathCapture: boolean or similar that, when set to true means that anything matching matchPath does not have static pages. Skip the extra request logic for those paths. I think this is more complicated for everyone to implement, but it should work if you prefer it for some reason.

All in all, please don't just dismiss this as a non-issue because it is for some of us.

[ghost]

@kilburn I'm experiencing the same issues you have mentioned, especially item number 4 in your list.

The 3 requests you describe and the 404 requests/abort are slowing down my authenticated routes in production test on Netlify.

It is tripping me up as I dev as well.

[bchehraz]

Ok so I'm having the same issue here, but it doesn't give me the 404 browser error until I build with prefixPaths for GitHub Pages (gh-pages@2.0). Here's a demo example of the Gatsby Simple-Auth project with the 404 error on gh-pages.

Gatsby Simple-Auth with gh-pages - (source code)

When running this same project locally, this warning pops up in the console once the page loads:

Error loading a result for the page query in "/app/profile". Query was not run and no cached result was found.
Page not found /app/profile
Error loading a result for the page query in "/app/details". Query was not run and no cached result was found.
Page not found /app/details

Even though the warning pops up when running locally, it still runs as intended with no 404 error in the browser.

[beamsies]

@bchehraz, @kilburn

Not sure why this is working for me, but it is...

gatsby-node.js file:

exports.onCreatePage = async ({ page, actions }) => {
  const { createPage } = actions

  if (page.path.match(/^\/app/)) {
    page.matchPath = "/*"
    createPage(page)
  }
}

Then in src/pages:
(pages are obvi examples)

const App = () => {
  Amplify.configure(config)
  return (
    <Router>
      <PrivateRoute path="/home" component={Home} />
      <PrivateRoute path="/profile" component={Profile} />
      <PublicRoute path="/signin" component={SignIn} />
      <PublicRoute path="/signup" component={SignUp} />
      <PublicRoute path="/reset" component={Reset} />
      <PublicRoute path="/" component={IndexPage} />
    </Router>
  )
}

Then in my 'components' folder the page components from above are those pages.

The routing errors have gone away, but now I need to render the 404 page properly (it currently does not show up or work). I may have to use the React-Router approach to this.

As for 'prefixPaths' I'm not using that outside of this implementation. I'll have a git repo soon, let me know if you care to view it.

The repo you referenced is out of date just a little. It's good but there's been a discrete change I think that I'm sure they're working on.

Update to the latest gatsby version, try the above implementation and let me know how it goes.

[bchehraz]

@ben-siewert I'd like to take a look at that repo once you have it up.

I updated the project to the latest Gatsby (^2.13.51). Without any further changes, the console warning when loading up the page has changed from what it says above in my previous comment to:

Page not found /app/profile
Page not found /app/details

And again, it works as intended when run locally. And when viewing on gh-pages it gives the same 404 error. I also updated the demo as well to reflect the Gatsby version change.

I tried the change you suggested just in gatsby-node.js which was just changing page.matchPath = "/app/*" to page.matchPath = "/*" and I got the same result and same console warnings. This held true for both running locally and on gh-pages. So I just changed it back to what it was previously "/app/*".

Also, @ben-siewert, in your const App = ... definition, it seems you are only using relative routes and no subroutes like in the Simple-Auth project:

const App = () => (
  <Layout>
    <Status />
    <Router>
      <PrivateRoute path="/app/profile" component={Home} />
      <PrivateRoute path="/app/details" component={Details} />
      <Login path="/app/login" />
    </Router>
  </Layout>
)

[TheHalcyonSavant]

@bchehraz I had the same problem with page.matchPath = "/app/*" and after doing some experiments I found that page.matchPath = "/*" was the only solution, just like you. But after some time for some other reason I run yarn cache clean, removed node_modules and yarn.lock, changed page.matchPath back to /app/* and everything was working again, just with Page not found /app/ dev error this time.

[bchehraz]

@TheHalcyonSavant 2 questions: Are you just running your project locally? And are you getting a 404 error in browser when visiting the page and look inside the console? For me, even with the Page not found warnings inside the gatsby develop console, I am still able to view the site as intended with no problems. It's only when I put it up on GitHub and add a pathPrefix that I get the 404 on the browser and everything comes to a halt.

I tried what you said- force cleaning cache using npm (I don't have yarn on my project) and using both page.matchPath = "/*" and page.matchPath = "/*" and I'm still getting the same warning. I also had removed .cache and public to make sure none of those were interfering. Still same issue.

It's also worth noting that in the Gatsby docs on Client Only Routes, it is suggested to use page.matchPath = "/app/*" in this case with /app being the chosen prefix

I barely started learning Routing with React/Gatsby this week and I'm still not completely aware of what Routers can do. Judging by Gatsby's behavior, is it possible that Gatsby is just complaining about the physical path /src/pages/app/<page_name> not actually existing?

[wardpeet]

@bchehraz It's only when I put it up on GitHub and add a pathPrefix that I get the 404 on the browser and everything comes to a halt.

could you explain pathPrefix here? I'm not sure if you need it.

@kilburn However, many of us would be able to solve it for our particular cases if you give us some kind of "escape hatch". In our case, we are using a routing scheme, meaning that we have just ~60 url patterns (that end up generating several thousand pages). We load those patterns in all pages because reasons, meaning that we can very easily verify if some url is a client path or a static path.

The idea is to try and release a plugin to fix this use case but there is no real time frame for this.

[colbyfayock]

A plugin feels like a bandaid though to an actual problem 🤔

[wardpeet]

Hey Colby!

Thanks for your message, and while we understand your frustration, we (Gatsby) don’t necessarily see it as a bug. The downside of making network requests and returning a 404 are negligible. The extra overhead it creates is not mitigated by the potential downside you’re experiencing.

Exposing a plugin to solve your particular issue seems like a fair compromise. Fixing the bug in core would mean less upside for other use-cases, so we’d prefer to expose this fix in a plugin to give you an escape-hatch to solve the issue.

Thanks!

[beamsies]

@bchehraz Here's the repo I said I'd send you a link to: https://github.com/ben-siewert/gatsby-starter-auth-aws-amplify. It works very well but now I just need to fix the 404 page as it doesn't currently render properly. I may have to achieve that with react-router.

@colbyfayock I did abandon the gatsby-plugin-create-client-paths even though it did work for me, I just didn't need it.

What I did was put every page in the app.js file, including the index page. Let me know how it goes!

[magicspon]

@wardpeet

we (Gatsby) don’t necessarily see it as a bug

This seems a bit odd to be honest. If Gatsby is billed as a solution for client side apps as well as static sites then this should surely be classed as a bug. However, I do agree that exposing a plugin is probably the best way to resolve this issue.

[colbyfayock]

If Gatsby is billed as a solution for client side apps as well as static sites then this should surely be classed as a bug

This

[bchehraz]

@wardpeet could you explain pathPrefix here? I'm not sure if you need it.

I'm just trying to show some projects on my portfolio with demos to try them out and I figured putting them on GitHub Pages would be the most convenient way of going about it. And to have a github pages link, there has to be pathPrefix like so https://<username>.github.io/<project_name>/...But it's proven to be very troublesome when it comes to client routing. Is there any other way you would suggest that I show off demos? I have not tried any other solutions yet for showing demos, but I am open to alternatives.

Edit: I used Netlify instead and now it has no issues, even with the 404s showing in the browser console. The warning also pops up in gatsby develop console for the project saying Page Not Found, but still works.

Here's a comparison between using pathPrefix and GitHub pages and using Netlify without pathPrefix. Source is up to date as well -

Simple-Auth Demo on Netlify, Demo on GitHub Pages with pathPrefix [Source]

As you can see, the Git pages demo has a 404 while the Netlify is working perfectly fine. Something is wrong with how Gatsby is handling pathPrefix, but I cannot pinpoint exactly why this is happening. As of now, I'm ok with just using Netlify and saying goodbye to using pathPrefix on GitHub pages.

[karldanninger]

Updating to 2.13.59 removes the warnings locally* 👍 thanks @freiksenet & @wardpeet !!! ❤️

Edit: Still warnings in console after build/deploy

[colbyfayock]

Confirming on 2.13.59 i'm not seeing the terminal messages in develop mode. Thank you for this.

I am however still seeing the 404 in the console on deploy.

is the official Gatsby position on this "Won't Fix" even with all of the other concern here? @wardpeet @freiksenet Otherwise this should be left open as it was partially fixed or a new issue with that specific concern, as OPs description included that as an issue, among the rest who commented.

You mentioned previously about this being a plugin fix (gatsby-plugin-create-client-paths?), if it's being tracked somewhere else, I would be happy to migrate my subscription over there, as I'd just like to see this resolved in my apps. Thanks

[magicspon]

I can confirm, I am still seeing errors in the browser console.

I don't think this should be closed if part of the issue is still active

namely:
"prefetch.js:33 GET http://MYDOMAIN/page-data/app/faqs/page-data.json net::ERR_ABORTED 404 (Not Found)"

[bsswartz]

The patch basically just hides the error message output by the development server. I believe that this fixes the actual issue in the original ticket here which they have treated as a nuisance logging issue.

Unfortunately the page-data.json 404 errors are more than spurious/nuisance logging and represent a logical flaw with the new Gatsby page-data scheme. There is already an issue representing the 404s, but it was closed as won't fix/can't fix. Perhaps we should address our concerns there as well.

#16097

[magicspon]

I believe that this fixes the actual issue in the original ticket here which they have treated as a nuisance logging issue.

The original ticket references both flavours of errors. In my opinion the browser error is more of an issue than the terminal warnings.