gatsby: Client only routes - Query not run warning

@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.

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

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

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!

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)”

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

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.

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

Edit: Still warnings in console after build/deploy

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

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

@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.

@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.

@break-paradigm I’ve encountered the flashing 404 thing myself. Doing this solved it for me https://github.com/gatsbyjs/gatsby/issues/5329#issuecomment-484741119

@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 😃

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

Closing as duplicate

Thanks, we are investigating this!