-
Notifications
You must be signed in to change notification settings - Fork 27.6k
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
Dynamic routes cause a "ChunkLoadError" when using the app router in a dockerized Next.js 13 SPA #54008
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
I am seeing the same issue in our Docker Environments reverting to version 13.4.9 is a temporary fix for the issue. Any urls with [] (%5B, %5D) return a 404 error which includes the generated js files for any dynamic page |
I can confirm this solution works. The issue begins occurring since version |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
I have more or less the same setup and the same issue (only dynamic routes), but I am only experiencing the error when I have Google Search Console "live test" my production URL, which makes this difficult to debug. I'm not able to reproduce the error in production via Chrome Beta. |
I am experiencing similar issues with Google Search Console "live test" on production URL for a site deployed on Vercel. It makes it difficult to get pages indexed in Google Search. It seems a little non-deterministic for me. Sometimes Google Search Console "live test" does not work on a page. Yesterday Google Search Console "live test" failed twice on a page then worked the third time. next@13.4.4 and app router deployed on Vercel |
@scottpaulin I realized that my issue is not limited to my dynamic routes. It affects a bunch of my pages. The Live Test fails about two thirds of the time. But I do think my pages are getting indexed as I can find them using Google Search and my production pages load just fine when I navigate to them in the browser. Perhaps it's an issue with the Live Test crawler erroneously thinking that a certain chunk is unnecessary and not loading it. I'm hoping it's not actually impacting SEO... |
@bryceAebi yea I have seen it in a static route too. Google also (eventually) indexes my pages. I think Google is recrawling pages every few days and eventually has a successful render. Ahrefs is showing lots of errors about failed metadata etc, I'm guessing it's because the render fails. Yea not sure if seo is being affected. Fingers crossed it isn't. Pretty scary issue for sites that rely on search traffic for revenue. I am seeing a bunch of http status 0 errors in datadog. Might be unrelated though. |
This comment was marked as off-topic.
This comment was marked as off-topic.
ive tested many versions and 404 ChunkLoadError in a Docker Environment and just no content and no error for non docker deployments. Super weird and very annoying. Also only on unix? I am unable to reproduce this locally - with any version. Even latest works fine. But as soon as I deploy on a ubuntu cloud server -> router is broken again. This affects both |
Yes, locally even the production version works fine for the latest version. The problem occurs only after deployment to a unix server. |
I develop and build on Docker env - so both I am seeing this issue on PROD builds (i.e. Dev env (again, Dockerized |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
For what it's worth, I have also had the same issue, and downgrading to |
Coupla days ago while checking 13.4.20-canary release notes I noticed a fix
there. Haven't tested them myself of course (because of @sentry packages
requiring proper nextjs versions), but I think the fix is coming.
…On Mon, Aug 28, 2023 at 5:09 PM Peter Western ***@***.***> wrote:
For what it's worth, I have also had the same issue, and downgrading to
13.4.12 resolves it.
—
Reply to this email directly, view it on GitHub
<#54008 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE7SANUAMJVKQZK4UGHF3DXXSYBTANCNFSM6AAAAAA3QA4B2I>
.
You are receiving this because you commented.Message ID: <vercel/next.
***@***.***>
|
Guys this caused me a lot of head scratching. Thanks for this issue! For the record (host OS: OSX):
The most confusing part to me was that even running in docker worked for me locally. Whenever I deployed it, on the production version it would show: "Application error: a client-side exception has occurred (see the browser console for more information)." It turned out to be this.
Hope this saves someone some head-scratching. I will investigate some more what might be going on here. |
13.4.12 - Latest stable version |
I have further narrowed down, that the breaking change must have been introduced in v13.4.13-canary.0 – it's the first version where this occurs. Looking at the changes, nothing stood out and unfortunately I lack the time for further analysis. Until then, we'll (have to) stick with 13.4.12 |
same issue here |
I've also been having this issue, and can reproduce Jan's observation that this broke between v13.4.12 and v13.4.13-canary.0, which contains the following commits: Another observation is the following: given a dynamic route parameter [slug],
Since the file exists on disk without any form of encoding, which also was the case in v13.4.12, that makes me think this likely is caused by a change in the included server. This commit changes to how files are resolved, particularly the diffs in // In dev, we ensure encoded paths match
// decoded paths on the filesystem so check
// that variation as well
const tempItemPath = decodeURIComponent(curItemPath)
fsPath = path.posix.join(itemsRoot, tempItemPath)
found = await fileExists(fsPath, FileType.File) I'm not really having any luck getting local changes to end up in the docker image, will try that again later... |
I've confirmed that 1398de9 is the cause of the issue. Looking at let curItemPath = "/_next/static/chunks/app/events/[slug]/page-8f8f16ccd387e59d.js";
let curDecodedItemPath = "/_next/static/chunks/app/events/[slug]/page-8f8f16ccd387e59d.js";
let items = [
// ...
"/_next/static/chunks/app/events/%5Bslug%5D/page-8f8f16ccd387e59d.js",
]; The entry in // ensure filename is encoded
nextStaticFolderItems.add(
path.posix.join('/_next/static', encodeURI(file))
) If I remove the Hey @ijjk - I hope you don't mind the mention - are you sure that the [edit] |
Final message from me, apologies for triple posting. While this definitely is a regression in NextJS, I found the underlying root cause for my case: nginx was messing with the URL. I use nginx to terminate TLS and reverse proxy the requests. When the I fixed it by changing my location rule from this:
to the following, after which the latest NextJS canary works just fine:
|
This was blocked on a regression in NextJS, which previously compensated for rather surprised behaviour from nginx. vercel/next.js#54008 (comment)
@shehi yes but I'd like to focus on the actual issue which is an obvious regression.
@AmirL , the same as @poorscousertommy8 I have this issue even with all lowercase, [lang] to be specific. We have mentioned the issue to several maintainers now and it is clear we need their support. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
I'm having also this issue and I'm not using a trailing slash in my nginx reverse proxy config Buggy config
I just found the fix, after reading this https://serverfault.com/a/463932 Working config
|
This comment was marked as off-topic.
This comment was marked as off-topic.
Been tearing my hair out over this bug today 😭. Was introduced in The problem is that when servers such as NGINX (& Apache) reverse proxy a request (using 200 ✅ `/_next/static/chunks/pages/%5Bparent%5D/%5Bchild%5D-hash.js`
404 ❌ `/_next/static/chunks/pages/[parent]/[child]-hash.js` # URL transformed by NGINX FWIW, this one-liner patch resolves the issue: ![]() cc. #54008 (comment) |
@jlalmes thanks for your insights. Would you mind adding a pr for this? |
Hi everyone, we are looking into this! The best way to help is to provide a minimal reproduction instead of "same issue", etc. comments. It should be clear from your reproduction if you are using nginx, standalone ( Note: Please refrain from tagging maintainers for visibility, the issue is already tracked, so we are aware. |
Minified version of the problem here: https://github.com/omarmciver/ui-example-web Spin it up with VSCode devcontainer extension. Include simple nginx config. The README.md give instructions on how to recreate, and fix by not using client side rendering. Using 13.5.3 |
TL;DR 🚀If you're using a configuration like this: location /next {
proxy_pass http://ui-example-web:3000/next;
} Change it to: location /next {
proxy_pass http://ui-example-web:3000$request_uri;
} resolver 127.0.0.11 valid=30s; If this helped you, consider buying me a coffee.Full Explanation 📖The Issue 🐛When NGINX is given a This leads Next.js to receive a decoded request URI for a static chunk, like so:
It (or webpack?) expects to receive it like so:
The Consequence ❌Next.js doesn't handle that decoded URI well and returns a 404 error. This issue is specific to The Solution 💡The workaround is to use NGINX variables. The Final Thoughts 💭Understanding both NGINX and Next.js behaviors is crucial. I use NGINX in development and NGINX ingress controller in a Kubernetes production environment. The same config change applies to both.
Feel free to share your thoughts and experiences. If this helped you, I'm still looking for help buying coffee. |
thanks @omarmciver for your detailed analysis. I would like to point out something from it in particular, because I suspect this to be the case for everyone here like me thinking this can't be related to nginx, because they're not using it. Initially I thought "Well this again doesn't concern me, because I'm not using nginx, but the nextjs standalone server."
I don't use nginx in development, but it turns out we DO use an nginx ingress controller in the kubernetes production environment. The bad news is: I have checked the config now and there is no special configuration for The good news is: We may have found the origin. Next needs to handle the encoding/decoding of the chunk URIs properly. It also means my initial gut feel pointing towards our ingress controller, which I mentioned in my initial error report, was probably correct. |
Sorry Balázs for the tagging. What I do is explained relatively simply: I run the setup according to the Next.js website (npx create-next-app@latest - incl. App Router) and create a folder in the app directory with a dynamic route ([...pagename ]). After deployment, loading the chunks fails. |
@janpaepke I can share with you the Kubernetes ingress solution a little later today. I don't know what, if any, blocker there is for nextjs handling a decoded uri. I might look at that previous commit that was referenced as introducing the issue. |
@janpaepke and others. PR #56187 It will remain in draft until I get time to write a test to support this. |
@omarmciver Thank you! |
Tysm for your efforts and contributions!! |
Still working on getting a test in place, then hopefully working my way to the top of the maintainers review list. Man, they have a lot of work! |
For all users who use windows and iisnode, there is a solution #54325 (comment). |
For all followers of this: There's movement in @omarmciver's PR. Looks like this might be solved soon. 🥳 |
This is fixed in latest patch release 13.5.4, please upgrade to the new version, thanks y'all for digging deep on this issue 🙏 |
i can confirm that this patch worked, i upgraded to 13.5.5 and all good again! |
people please stop spamming, this is not a discussion but an issue, and I only want to get updates when there is progress, if it works for you just 👍the first message that says it started working or the issue got fixed. |
Verify canary release
Provide environment information
Operating System: Platform: linux Arch: x64 Version: #85-Ubuntu SMP Fri Jul 7 15:25:09 UTC 2023 Binaries: Node: 18.15.0 npm: 9.5.0 Yarn: N/A pnpm: N/A Relevant Packages: next: 13.4.15 eslint-config-next: N/A react: 18.2.0 react-dom: 18.2.0 typescript: N/A Next.js Config: output: N/A
Which area(s) of Next.js are affected? (leave empty if unsure)
App Router
Link to the code that reproduces this issue or a replay of the bug
https://github.com/eide-1/sample-project
To Reproduce
Steps to Reproduce:
Describe the Bug
I am currently working on upgrading an existing Next.js SPA that uses the pages router to the app router. The project is deployed using Docker and Nginx. However, I noticed that dynamic routes cause a "ChunkLoadError" when the SPA is deployed in a production environment. All pages (including dynamic routes) are functional in a development environment.
The dynamic route in question uses the "use client" directive. I noticed that if I remove the "use client" directive and any component or hook that requires it from the page, I can get it to render properly in production mode.
I created a sample project that uses the same tech stack as my current SPA to demonstrate the issue and I included the steps to reproduce the issue below.
I also found the following Stack Overflow question detailing a similar issue to the one I described above: In Next.js 13 using App Router, why can't I export dynamic routes with "use client"?
Expected Behavior
Dynamic routes should work in the production environment just like they used to under the pages router without causing a ChunkLoadError.
Which browser are you using? (if relevant)
Microsoft Edge 115.0.1901.203 (64-bit)
How are you deploying your application? (if relevant)
Docker/Nginx
NEXT-1641
The text was updated successfully, but these errors were encountered: