-
Notifications
You must be signed in to change notification settings - Fork 88
fix: support non-prerendered dynamic routes with fallback false #1541
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
✅ Deploy Preview for netlify-plugin-nextjs-demo ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
✅ Deploy Preview for next-hp-edge-demo ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
❌ Deploy Preview for netlify-plugin-nextjs-nx-monorepo-demo failed.
|
✅ Deploy Preview for netlify-plugin-nextjs-export-demo ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
✅ Deploy Preview for next-plugin-canary ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
✅ Deploy Preview for next-plugin-edge-middleware ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
✅ Deploy Preview for netlify-plugin-nextjs-next-auth-demo ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
✅ Deploy Preview for next-i18next-demo ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
✅ Deploy Preview for nextjs-plugin-custom-routes-demo ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
✅ Deploy Preview for netlify-plugin-nextjs-static-root-demo ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
❌ Deploy Preview for next-plugin-rsc-demo failed.
|
Is the motivation for this due to Matt's comment or is this a nice to have? I'm not sure this is necessary (unless I'm missing something) as it appears it's the intended behavior according to the docs (excerpt below).
|
a5b8971
to
8a361ae
Compare
Thanks @hu0p, that last item on the checklist is just because the current behaviour will render all locales regardless of whether a user specifies them in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't totally understand what's happening with the SSG cache. What happens when it tries to write to disk? Does it handle the failure? Is this being done so that it can return the prebuilt placeholder HTML?
Got it. Thanks for the clarification! Watching this as much as I can. I appreciate both of your work on all of this. Thank you! I've been eying that highlighted portion of the redirects file off and on for months. When this lands it'll be a huge resolution for us. |
@ascorbic without an I will switch to the header method, which will remove the need for the 1st patch, and I may be able to avoid the 2nd patch too with the |
@@ -1,7 +1,124 @@ | |||
describe('Static Routing', () => { | |||
it('loads show #42 via SSR on a static route', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you need to include the show numbers here. Just "the correct page" or something
…ugin-nextjs into rs/fallback-false-fix
…ugin-nextjs into rs/fallback-false-fix
Summary
Next.js uses an internal cache to persist page creation and updates during incremental static regeneration (ISR).
In order to preserve atomic deploys, Netlify has a different model that uses our ODB functions for creating and updating pages after deployment.
To support this, we currently patch the Next.js server to disable the internal cache, which ensures our ODB functions always receive fresh content and can handle the caching and revalidation directly.
However, our current solution has an incidental bug that bypasses the
fallback: false
andfallback: true
functionality and always serves the page likefallback: blocking
. In addition, it creates an unnecessary function invocation and runsgetStaticProps
unexpectedly.Fixing this bug enables support for all the fallback options, but doesn’t work in one specific case: pre-rendered ISR pages with
fallback: false
and a revalidation TTL. These pages get served as a 404 because there is no fallback and the server thinks there is no statically pre-rendered page. This does not happen for ISR pages without revalidation because they are served statically, bypassing the origin entirely.This PR implements a different strategy: we continue to disable cache writes, but enable cache reads and force manual revalidation mode so fresh content is always served.
Further work is currently ongoing in order to support bypassing the ODB handler for 404 pages.
fallback: false
andfallback: true
, but force manual revalidation for fresh contentTest plan
See test coverage
Relevant links (GitHub issues, Notion docs, etc.) or a picture of cute animal
Fixes #1179
🧪 Once merged, make sure to update the version if needed and that it was published correctly.