fix(gatsby): remove 404 pagedata logic on client side pages

[wardpeet]

Description

We have got a few complaints about page-date returning 404s when doing client side only pages. We fetched page-data of every page and when it returned a 404 we fallback to matchpath.

This pr writes pages that are inside a matchpath to matchpath.json so we can safely rely on match-path.json.

It reverts most of #15762 which was added to do the 404 page-data checks.

Still on my todo is to add a simple test for the findPath function.

Related Issues

Fixes #16097

[wardpeet]

looks like tests aren't passing yet

[wardpeet]

I've tested it manually and our e2e tests cover it basically pretty well.

I've published a canary version on gatsby@page-data-404

[sidharthachatterjee]

This looks great overall to me! Will hold off on merging this in for now since you've added the needs manual testing label

[oorestisime]

Not sure if this is helpful but i tried this with a project that was impacted by these 404s (and limiting page speeds) and problems "vanished". thanks for working on this :)

[alampros]

Just tested this on a project with gatsby-plugin-offline and it has definitely helped (thank you!). Without it, the 404s were throwing the app into an unrecoverable state while offline.

[wardpeet]

It seems like there are some troubles with prefetching page-data that is still happening, I can't really reproduce it so I would suggest merging this one and I'll ask for reproduction for a follow-up fix.

[sidharthachatterjee]

Looks good!

[JustFly1984]

@wardpeet I have issues with / page and localized copies /ru/ and /en/, rendering as 404 page after this PR was merged and published in 2.15.23

All other pages rendering properly. rolling back to 2.15.22 solves an issue.

I have created this issue: #17980

[antoinerousseau]

Same here, had to rollback to 2.15.22, otherwise pages created with createPage() are not accessible and land to 404 instead.

[metamn]

Hmmm ... rolled back to 2.15.22 but still this particular post gives 404: http://metamn.io/react/react-follows-the-functional-reactive-programming-paradigm/

Try to refresh it: First the page is rendered then it is replaced by the 404.

I've done everything: empty cache, renamed the post twice, upgraded all packages ... and nothing.

Thanks!

[metamn]

If it helps: the 404 comes from page-data.json

[mi-na-bot]

@metamn Do you have a matchPath or client only route to provide the 404 page? Can you share the contents of .cache/match-paths.json in your project?

[metamn]

@Sever1an For the first question: I don't know but here is the repo: https://github.com/metamn/react
For the second:

[]

[mi-na-bot]

@metamn Probably not related to the issue reported above by JustFly1984.

A brief examination reveals that the page is attempting to fetch the page-data.json from an incorrect url: http://metamn.io/react/page-data/-follows-the-functional-reactive-programming-paradigm/page-data.json

The page-data.json does exist at the correct url: http://metamn.io/react/page-data/react-follows-the-functional-reactive-programming-paradigm/page-data.json

[metamn]

Thanks @Sever1an !!

Any hints why is that? Cleaning cache would help?

[metamn]

Or should I file a separate issue?

[mi-na-bot]

I think it would be helpful to create a new issue referencing your suspicion that it started with this pull request and sharing the insight about searching at the wrong url for a page-data.json that exists.

If possible please create a tag or branch of a version of the site known to cause the problem and reference it too.

The Gatsby core team is at a conference and not available this week so keeping things as well structured and clean as possible here will help tremendously.

[metamn]

Thanks again! :)

[mi-na-bot]

@antoinerousseau Do you have a github of the affected project? Do you have anything in .cache/match-paths.json after a build?