Nuxt 3.7+ : net::ERR_CONTENT_LENGTH_MISMATCH with VS Code Devcontainer

[ddahan]

Environment

Nuxt 3.7+

Reproduction

Note: the exact same codebase on Stackblitz works (including same node/npm versions), I suspect this is somehow related to my local environment. Here is below a repository reproduction containing a VS Code dev container:

Reproduction steps

• Install Docker (I'm using Docker Desktop for Mac)
• Install VS Code and VS Code Dev Container extension
• Open VS Code, run the Clone Repository in Container Volume command, providing this url: https://github.com/ddahan/nuxt-starter-dev-container
• Once the container is installed, run npm run dev in a terminal, and open Chrome Browser with the localhost url link.
• Open the inspector, this should display the ERR_CONTENT_LENGTH_MISMATCH error.

Describe the bug

I have 3 projects running Nuxt (3.5 and 3.6). After upgrading any of them to Nuxt 3.7, I get an net::ERR_CONTENT_LENGTH_MISMATCH error in the browser when loading the page. The error happens on different potential files, and the site is basically unusable (not loaded completely, not clickable, etc.).

I'm using VS Code dev containers, which means the browser I'm using locally connects to a Docker container using port forwarding.

• I tried using 3 local browsers but the error is the same.
• I tried to run the server with the --host option but I got the same error.
• I ensured there is enough space disk on my container

Any idea of what could have happened? I read the Nuxt 3.7 changelog and it seems there are many low-level changes that could explain this, but I'm not competent enough to understand.

Thanks.

EDIT: video added https://github.com/nuxt/cli/assets/1933516/77acf4ce-411f-4493-85ad-5f8feb5b3467

[github-actions[bot]]

Would you be able to provide a reproduction? 🙏

More info

### Why do I need to provide a reproduction? Reproductions make it possible for us to triage and fix issues quickly with a relatively small team. It helps us discover the source of the problem, and also can reveal assumptions you or we might be making. ### What will happen? If you've provided a reproduction, we'll remove the label and try to reproduce the issue. If we can, we'll mark it as a bug and prioritise it based on its severity and how many people we think it might affect. If `needs reproduction` labeled issues don't receive any substantial activity (e.g., new comments featuring a reproduction link), we'll close them. That's not because we don't care! At any point, feel free to comment with a reproduction and we'll reopen it. ### How can I create a reproduction? We have a couple of templates for starting with a minimal reproduction: 👉 https://stackblitz.com/github/nuxt/starter/tree/v3-stackblitz 👉 https://codesandbox.io/s/github/nuxt/starter/v3-codesandbox A public GitHub repository is also perfect. 👌 Please ensure that the reproduction is as **minimal** as possible. See more details [in our guide](https://nuxt.com/docs/community/reporting-bugs/#create-a-minimal-reproduction). You might also find these other articles interesting and/or helpful: - [The Importance of Reproductions](https://antfu.me/posts/why-reproductions-are-required) - [How to Generate a Minimal, Complete, and Verifiable Example](https://stackoverflow.com/help/mcve)

[danielroe]

I believe the issue is upstream in nuxt/cli, and may already have been fixed. Would you try with v3.8.3?

[pi0]

By any chance are you using an endpoint with DELETE method? (because it is a known issue -- however not new one)

[ddahan]

I believe the issue is upstream in nuxt/cli, and may already have been fixed. Would you try with v3.8.3?

@danielroe I'm already on latest versions (Nuxt 3.7.3 and Nuxi 3.8.3) and the error still occurs. I added a video in the issue description and refreshed the page multiple times to show how the error is displayed.

I also ensured there is enough space disk on my container.

[ddahan]

By any chance are you using an endpoint with DELETE method?

I may have some DELETE endpoints but the error occurs before reaching them. On any website I tried, the error occurs at index page loading. By the way, one of the repository is a fork of Nuxt UI so it should work.

[ddahan]

Side question: if I'm able to build a minimal reproduction repository containing a VS Code .devcontainer file, are you able to run it? (you'd need VS Code and Docker Desktop for this). I'm asking because I suspect the problem can't be reproduce on a local environment.

[pi0]

Yes, docker env / devcontainer is even better!

[or2e]

related: https://github.com/nuxt/cli/issues/118

[ddahan]

@pi0 @danielroe I created a minimal repository containing a .devcontainer file for reproduction (see the initial updated issue). Are you able to reproduce the issue? Thanks!

[pi0]

Thanks! yes I can reproduce it. Seems coming from the vite handler.

GET http://127.0.0.1:3000/_nuxt/node_modules/.cache/vite/client/deps/vue-router.js?v=38dcfad8 net::ERR_CONTENT_LENGTH_MISMATCH 200 (OK)

CLI warning might be related:

[Vue Router warn]: No match found for the location with path "/_nuxt/@vite/client"

Something to add is if you open the network tab and disable the cache, this issue will be gone. (this might be simply a warmup cache timing issue)

/cc @antfu Do you have any guesses?

[ddahan]

Any update on this?

The error actually breaks any repository using Nuxt (like Nuxt UI). I tried to disable the cache but it has no effect.

[max06]

I need to chime in here - exact same scenario.

Latest nuxt/nuxi in a freshly created devcontainer. Also with Nuxt UI.

To add some observations here: It doesn't always fail and it's not always the same ressource. This one failed at:

Loading the file directly shows a size of 191kB when it works and 130kB if it doesn't. Fetching that file using curl from inside the container works fine. Since devcontainer ports aren't actually real docker forwarded ports, I'd suspect vscode to cause the issues here.

[ddahan]

I'd like to add that it fails even without nuxt UI for me. For me it always fails, but indeed, not always with the same file(s).

As it still works with nuxt 3.6, I'm wondering what change in the 3.7 could explain this VS Code dev container incompatibility.

[max06]

Also worth mentioning: vscode recently updated to nodejs 18. It's not the first issue caused by that update.

[max06]

As it still works with nuxt 3.6,

It took a while to process this bit... do you mean nuxt 3.6 works fine with the current vscode release?

[ddahan]

Yep.

No problem with this VS Code and Nuxt 3.6.5 (and latest nuxt UI)

[max06]

I was able to trace the issue down to

root@463d9cf38f77:/workspaces/nuxt# git bisect bad
abd5d857705fa830d6ef019cb8a5ed3c763b7cd5 is the first bad commit
commit abd5d857705fa830d6ef019cb8a5ed3c763b7cd5
Author: Daniel Roe <daniel@roe.dev>
Date:   Fri Aug 25 16:20:32 2023 +0100

    feat(nuxt): migrate to new `nuxt/cli` (#22799)

Let's see if that helps in finding the issue...

[ddahan]

For the diff -> https://github.com/nuxt/nuxt/commit/abd5d857705fa830 Basically this commit is related to a full rewrite of the nuxt CLI using another framework (unjs/citty).

[max06]

I'm not sure if I can bisect my way through that one without having a direct check... I'd need a way to distinguish between bad because our issue and bad because incompatible with nuxt.

(Rephrasing: I'd need a good state as a starting point)

[or2e]

Fingers crossed P.s. we've given up on .devcontainer for now.

[ddahan]

we've given up on .devcontainer for now.

@or2e just curiosity: why not keep devcontainers and stick to Nuxt 3.6.5 in the meantime? Dev containers are so important to me, that I'll prefer go to React if never solved 😃

[pi0]

Hi again. Sorry hearing you still have issues with DevContainers. It is something we should investigate and fix for CLI proxy.

In the meantime, have you tried with nuxt dev --no-fork? It might fix possible issues.

[ddahan]

have you tried with nuxt dev --no-fork

@pi0 It just creates another error: [GET] "http://[::]:3000/__nuxt_vite_node__/manifest": fetch failed

As a reminder, I provided a reproduction repo with a devcontainer file. Do you need anything else to help investigate? (time, I guess ? ^^)

[max06]

Hello @pi0 and good morning,

since I'm no developer - can you tell me in a handful of steps how I can replace the cli in my nuxt development version with a local clone of this repo, so I can use git bisect on it? If the earliest possible commit (roughly around the time the cli was replaced in nuxt) doesn't show the current issue or prolonged loading times, I'm probably able to identify the commit which started this issue.

If it helps, I'm on your discord server, I just can't dm you. Look for "Flo".

[pi0]

@ddahan See https://github.com/nuxt/cli/issues/181#issuecomment-1719072945 -- After disabling cache issue seems to be solved.

[ddahan]

@pi0 See https://github.com/nuxt/cli/issues/181#issuecomment-1732378128 -- As I said disabling the cache had no effect for me. To be more specific, there is currently no workaround for me, except staying on Nuxt 3.6.5

[pi0]

It just creates another error: [GET] "http://[::]:3000/__nuxt_vite_node__/manifest": fetch failed

@ddahan It seems another issue with DevContainers reporting IPv6 as a listener ({ address: '::', family: 'IPv6', port: 3000 }) but not being available. It is unrelated but will work on it.

In the meantime can you please try with --no-fork --host 127.0.0.1?

Main, thing making this issues investigation tricky is that it not always happens. i have a local dev container that does not reproduces this issue anymore. I understand it happens for you and is frustrating but we need stable way to reproduce and fix things like this.

Feel free to also DM me in discord (@pi0) if you like to have a chat maybe sharing your screen.

[pi0]

Thanks for helping and upstream issue report dear @max06

I have pushed a .devcontainer setup to this repository. (https://github.com/nuxt/cli/commit/b8f9fd3a0c1ace6c3f548cc8a92d76f4be0eb43d).

After cloning repo, you can reopen it in dev container and then run pnpm install / pnpm build --stub and then you can run any state of repository using pnpm run dev (it opens playground/ in dev mode).

This issue is most likely a combination of IPv6 stack issues with proxy layer. When using --no-fork --host 127.0.0.1 we disable this proxy layer.

[max06]

I reported the ipv6 issue in vscode a while ago and it was already fixed. This shouldn't matter anymore at least for vscode features.

If nuxt listens on ipv6, that would be another issue to solve.

Regarding your flags: I can confirm it works, but only if I specify both of them. If I only use --host ..., it works, but we're back to slow speeds (and failed requests). Only using --no-fork causes the 500 errors mentioned above.

Just in case: I'm always testing on vscode insiders

[pi0]

I reported the https://github.com/microsoft/vscode/issues/191945 a while ago and it was already fixed. This shouldn't matter anymore at least for vscode features.

Thanks for the previous reports and references it was helpful!

If nuxt listens on ipv6, that would be another issue to solve.

It is mainly an issue with Docker+Node.js. Nuxt requests the default host, and Node.js inside containers wrongly reports an IPv6 interface which makes issues with Nuxt internal calls.

Regarding your flags: I can confirm it works, but only if I specify both of them. If I only use --host ..., it works, but we're back to slow speeds (and failed requests). Only using --no-fork causes the 500 errors mentioned above.

If you specify both --no-fork --host 127.0.0.1 flags, while having a slower performance (which is expected and will be fixed), do you also still experience ERR_CONTENT_LENGTH_MISMATCH error locally? Also if you disable cache in devtools is there any difference?

[ddahan]

can you please try with --no-fork --host 127.0.0.1?

I don't have the ERR_CONTENT_LENGTH_MISMATCH error anymore, but got another error related to nuxt UI dependency popper.js, but can't say if it's related to these flags or not for now.

Disabling cache makes no difference for me.

[max06]

With both flags, both issues disappear (for me).

Compared to

(for once without failed requests)

Browser cache doesn't seem to make a big difference at all, maybe 20% on the loading time.

[pi0]

Via #242, the --host flag is not required anymore in forkless version (therefore no slow speed)

@max06 @ddahan Can you please try latest change via npx nuxi-edge@3.9.1-1696342776.a6acb6a dev --no-fork in your project? 🙏🏼

[max06]

root@463d9cf38f77:/workspaces/nuxt# npx nuxi-edge@3.9.1-1696342776.a6acb6a dev --no-fork
Nuxt 3.7.4 with Nitro 2.6.3                                                2:33:35 PM

[2:33:35 PM]  ERROR  Error: Cannot find module @nuxt/kit imported from file:///workspaces/nuxt, file:///workspaces/, file:///workspaces/nuxt/_index.js, file:///workspaces/node_modules

  at resolvePath (/root/.npm/_npx/9bcd1de19fdfa663/node_modules/nuxi-edge/dist/shared/nuxi-edge.4354f916.mjs:7954:10)
  at importModule (/root/.npm/_npx/9bcd1de19fdfa663/node_modules/nuxi-edge/dist/shared/nuxi-edge.0458f9cb.mjs:11:30)
  at loadKit (/root/.npm/_npx/9bcd1de19fdfa663/node_modules/nuxi-edge/dist/shared/nuxi-edge.e7cda0de.mjs:9164:21)
  at async Object.run (/root/.npm/_npx/9bcd1de19fdfa663/node_modules/nuxi-edge/dist/chunks/dev.mjs:173:32)
  at async runCommand$1 (/root/.npm/_npx/9bcd1de19fdfa663/node_modules/nuxi-edge/dist/shared/nuxi-edge.77fb2b26.mjs:1647:7)
  at async runCommand$1 (/root/.npm/_npx/9bcd1de19fdfa663/node_modules/nuxi-edge/dist/shared/nuxi-edge.77fb2b26.mjs:1638:11)
  at async runMain$1 (/root/.npm/_npx/9bcd1de19fdfa663/node_modules/nuxi-edge/dist/shared/nuxi-edge.77fb2b26.mjs:1770:7) 

[2:33:35 PM]  ERROR  Error: Cannot find module @nuxt/kit imported from file:///workspaces/nuxt, file:///workspaces/, file:///workspaces/nuxt/_index.js, file:///workspaces/node_modules

Tried it in the nuxt devcontainer...

[pi0]

Is /workspaces/nuxt a valid Nuxt project? (This command should be run when you are in the directory of an installed Nuxt project to work properly) -- also dependencies in node_modules being installed

[max06]

Ah, my bad. Executing in a starter project seems to work. Loading time is down to 1 second, compared to the 60 seconds it took before. No request issues seen so far.

Do you have a solution in mind for the --no-fork-option?

[pi0]

Loading time is down to 1 second, compared to the 60 seconds it took before. No request issues seen so far.

Awesome!

Do you have a solution in mind for the --no-fork-option?

Yes. However not %100 sure if it resolves same root cause but to overcome internal networking issues, i plan to use IPC Sockets from main process to child. It works well for another proxy layer (Nitro) so I'm hopeful.

-- If it doesn't works well, i think in short term we can enable this flag by default for Docker environments (already enabled for Test and Bun)

[max06]

That sounds good!

Is there anything we should report to vscode, anything they can or have to fix to not need workarounds anymore? Otherwise I'd close the issue I opened for that.

[pi0]

I think VSCode side should be fine as far as i tested. Root cause is mostly Docker networking issues With Node.js/IPv6... Thanks for following up btw!

[max06]

No worries, I'm here to help as much as I can. And I seem to attract bugs whenever I touch something 😅

I probably should have mentioned my docker containers are ipv6 enabled. However I'm totally fine if everything inside docker uses ipv4.

And before I forget it: Thank you very much for your quick fix!

[ddahan]

@max06 @ddahan Can you please try latest change via npx nuxi-edge@3.9.1-1696342776.a6acb6a dev --no-fork in your project? 🙏🏼

@pi0 it removes the main error 🙏🏼 thanks for your help!

(Sorry I had a cross bug that seems related to Nuxt UI popper.js dependency in the middle of my tests, which complicated everything).

[ddahan]

Hi there! Same issue with nuxt 3.8.0 unfortunately. Any progression on this?

Is there anything I can do/try to help debugging? Thanks for your help @pi0

[ddahan]

@rstainsby I'm not sure you're issue is the one I described. Mine is not related to fetch or delete method. It happens on any project even on a hello world.

[rstainsby]

Apologies, I was looking at several issue relating to CONTENT_LENGTH_MISMATCH and I posted that comment under the wrong one. Thanks for letting me know.

[Suniron]

Same, i have this error ERR_CONTENT_LENGTH_MISMATCH in browser console.

I'm using devcontainer under Windows 11 WSL2 (Ubuntu).

I got also sometimes this error: Uncaught (in promise) DOMException: Cache.put() encountered a network error.

These errors only appears on my Nuxt Bridge app, my Nuxt 3 app (in the same monorepo) is OK

[jeanmatthieud]

Waouuu... I was using Nuxt3 for a project for a while with devcontainers, and it was painfully slow (compared to Nuxt2), with a initial load time (under Chrome) often over a minute (worse than @max06), but I never found anyone speaking directly of this issue, and did with it.

I recently had lot more ERR_CONTENT_LENGTH_MISMATCH errors (after upgrading Nuxt and all dependencies), and the dev was impossible. I added the --no-fork option to the dev command. The website is now loaded in less that 5 seconds, and the err content length mismatch disappeared! After a while dealing with this long loading time, it feels like magic 🧙‍♂️!

[Suniron]

With your suggestion, i got this error :/

[GET] "http://[::]:3003/__nuxt_vite_node__/manifest": fetch failed

[jeanmatthieud]

These errors only appears on my Nuxt Bridge app, my Nuxt 3 app (in the same monorepo) is OK

I tried to migrate from Nuxt2 to Nuxt Bridge (before Nuxt3), but it was a nightmare, with all the dependencies. I re-created a project with Nuxt3 from scratch, and migrated the code as quick as possible. It was not an easy task...

[Nefcanto]

We're getting this error in Vite + React. It seems that this error is not related to a specific framework. It might be something related to the container, or maybe even the linux, or even Chrome.

[marcotuna]

Same problem here. Not using nuxt, however I am using React + Vite while port forwarding using VSCode. Accessing using the direct url works, using port forward, doesn't.