Vite dev hangs indefinitely without errors on page with many components and imports

[hanszoons]

Describe the bug

I use SvelteKit. I have a somewhat complex page that contains quite a lot of components and imported functions. I had sporadic problems with this page hanging in the browser (both Firefox and Chrome). However, no error or notification in the vite cli. I was usually able to fix this by restarting the dev server several times whether or not in combination with restarting the browser. Other, simpler pages, always just kept working. Restarting my computer always works.

In recent days, I have been adding extra functionality, and the more I added, the more often the page kept hanging and the harder I got it to work again. When I get the page online (after frequently restarting everything I get restarted), everything just works. Until I make an adjustment in the code and because of the HMR the thing hangs again. I don't see any other pattern to it.

The problem does not occur when I build and preview the page, the production code always works.

It's driving me crazy, I can hardly get anything developed.

Reproduction

I can't build a reproduction, there is no pattern.

Steps to reproduce

It happens only on the dev server. I can find no pattern, cannot pinpoint a cause and thus cannot foresee any reproduction. There is nothing wrong with the code itself, the production build works perfectly.

The debug logs below are what I get when browsing to /leerlijn/54159. It starts doing it's thing, and then just randomly stops at some point.

System Info

System:
    OS: macOS 13.0.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 12.20 GB / 32.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.12.1 - ~/.nvm/versions/node/v18.12.1/bin/node
    npm: 8.19.2 - ~/.nvm/versions/node/v18.12.1/bin/npm
  Browsers:
    Chrome: 108.0.5359.124
    Firefox: 108.0.1
    Safari: 16.1
  npmPackages:
    vite: ^4.0.3 => 4.0.3

Used Package Manager

npm

Logs

Posted here: https://gist.github.com/hanszoons/2c511fa66ad76bd5181f84f7f7115eb5 because of the maximum 65536 characters.

These are the logs when requesting the page /leerlijn/54159, after wich it simply hangs indefinitely.

The second file are the logs when the page is rendered successfully. Same exact code, same config, same everything. Just some dev server restarts and good luck. 1 code change with HMR and the thing hang again.

Validations

• [X] Follow our Code of Conduct
• [X] Read the Contributing Guidelines.
• [X] Read the docs.
• [X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• [X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• [X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• [X] The provided reproduction is a minimal reproducible example of the bug.

[fc]

I have also run into chrome spontaneously crashing (well just the tab) seemingly due to HMR but there was nothing useful that came out of verbose logging or anywhere else. When you say it stops working/hangs, what does it show in the browser?

[hanszoons]

When you say it stops working/hangs, what does it show in the browser?

Nothing at all. Just a pending request and a spinner. The hanging only happens on requests to this 'route'/page, the vite process/server still accepts other requests even after the hanging happened. And handles them just fine without requiring a restart.

I have no idea where to even start to 'debug' this problem.

It does not seem chrome related, it happens in Firefox and Safari as well.

[hanszoons]

I found a (consistent) way to temporary fix a hanging route.

• I delete a bunch of imports (and the code using them) in the file.
• Restart the server.
• Reload the hanging page (it loads).
• Paste imports back in the file. Save.
• HMR does it's thing.
• Route can be reloaded and works fine.

Changing anything in one of the imported files (something as simple as adding a console log) can result in the HMR making the page hang again.

[fc]

I've run into infinite pending requests and other issues but here are a few thoughts that maybe will help you although what you describe doesn't sound exactly the same as what I ran into...

Untrusted SSL/cache issues - for SSL we needed to have a trusted SSL certificate - it doesn't look like you're using SSL based on your screenshot but mentioning it just in case because there were equally frustrating and baffling issues with that. Using an untrusted SSL could lead to unexpected behavior since it wouldn't correctly cache anything. I see that 'Disable cache' is checked in your screenshot, and I wonder if that is maybe causing problems (or just a coincidence).

Infinite pending requests - the infinite pending request problem that we had was caused by a bug in http that we could never fully root cause (http is used under the hood by the vite proxy). To workaround this, we setup a proxy that doesn't use node at all that would act as a reverse proxy to all requests to vite, e.g., localhost:9000 would proxy all the requests to localhost:5173. We also had to remove to the server.proxy settings from our vite config. There is a GitHub issue that says this may be a problem with a file descriptor limit although increasing the file descriptor limit didn't seem to resolve it for us.

[wtachau]

I have seen this as well, with SvelteKit. In my case I get a log that ssr compilation starts, but it never finishes. It is non-deterministic and only happens in dev. If you figure out what's causing it, I'd love to know— it's driving me crazy.

[mike-lischke]

Same problem here, but with a preact app that uses web workers with very large TS files (a parser). HMR is not my problem, though. I can run the app once. Have to wait a couple of seconds until everything is loaded. Then I go to the page that requires parsing and get a couple of these messages:

[BABEL] Note: The code generator has deoptimised the styling of undefined as it exceeds the max of 500KB.

Once the last of the message is through I can actually use the page and the worker (pool) works. Then I try to restart the app and nothing works anymore. It just hangs and after a while I get a timeout error.

When I now try to stop the dev server (by pressing q in the VS Code terminal) nothing happens. Same for ctrl+c. I have to kill the process and start the dev server again before I can continue. This is so annoying. If I only had a log that would tell me what's going wrong...

[mike-lischke]

Following the advice from @fc I disabled https and that seems to help with my issues. I used "@vitejs/plugin-basic-ssl" to provide a self signed certificate.

I then checked also HMR and the updates are instant! So https seems definitely to be an issue with the dev server/browser.

[fc]

@mike-lischke if you do need/want https, you need to trust the ssl by manually setting it to be trusted in Keychain Access on macOS.

I had submitted a PR that added instructions/info about this on the troubleshooting page.

https://github.com/vitejs/vite/pull/11126

[mike-lischke]

Yes, I know. We do this automatically in our VS Code extension. But for the dev builds I hoped I could get away with that plugin and didn't expect such troubles once the browser accepted the connection. Thanks a bunch for your help @fc!

[mike-lischke]

Update: I removed the basic-ssl plugin and set up the dev server to use our (self signed) server cert. Everything connects and the page looks good at first look. But as soon as I start using the web workers I'm back to square one: after reloading the page or restarting the browser entirely, the web workers don't do anything anymore and the dev server just hangs.

In fact it looks as if the dev server doesn't serve anything from this moment on. When I do yet another page refresh in the browser I only get a timeout error.

[Creskendoll]

I am also having the same issue. The dev server hangs seemingly randomly and the site is not accessible on subsequent restarts. The built version works fine but I'm unable to work on the project locally which is very annoying.

I'm also using Sveltekit on a relatively big project so I cannot reproduce it. I've tried using the older versions of Vite, going back to 4.0.0, and the issue happens on all versions.

This leads me to believe that this might be a Sveltekit issue.

Might not be related at all but I noticed that the site hangs each time after this message: ✨ optimized dependencies changed. reloading

[mike-lischke]

I don't use Sveltekit and had to switch to non-secure connections (http) during debugging (which is not a big deal, just a bit annoying, having this working for such a long time, before I switched to vite).

[fc]

Based on this comment - has anyone tried using an older version of node (16.15 instead 18.x) - this could be a possible solution for the infinite pending requests in the network tab: https://github.com/vitejs/vite/discussions/7620#discussioncomment-3108701

[Creskendoll]

@fc I am using v16.18.0. I tried 16.15.0 and the same thing still happens. I've been using the same version of Node all along and this issue started happening recently.

[ruigil]

I have exactly the same problem, and I've managed to solve it for my case, but I'm not sure if this the solution to every other case in this thread. So my problem was:

• Running in dev mode http://localhost:5173
• Complex React page with lot of components in TS
• Vite dev hangs indefinitely without errors randomly after a while

I'm developing on WSL on windows, and the localhost is routed to WSL. Instead of running vite on localhost, I do vite --host 0.0.0.0 and access it with the WSL network in my case http://172.20.102.240:5173/
With this setup vite runs fine, but I'm not sure this is a WSL problem, because I have node servers on WSL and they run fine with localhost.

Hope this helps somebody !

[roligheten]

I think I am having the same issue, ie. specifically when running the vite dev server the browser tab will hang on the initial load.

However for me it is not just that the vite dev server is not responding, it seems like the browser tab is frozen, ie. when I press the close or back button on the tab in chrome it will not respond, and I need to press close many times to force close the tab from chrome. Is anyone else experiencing the same behavior in Chrome?

Should also note that in my team I am the only non-Mac user, and none of the Mac users seems to be having issues. (I am on Linux)

[Creskendoll]

@roligheten That sounds like you have an infinite loop somewhere in your app.

In this particular issue, the dev server fails to respond during server-side rendering. I am using SvelteKit and In my case, the fetch requests made from +layout.ts never resolve. Those requests are made to the SvelteKit endpoints like /account/me.json and those endpoints never receive the requests. This causes the load function to never finish since it's stuck awaiting the requests to resolve, thus hanging the app indefinitely.

// +layout.ts
// This runs but never resolves
const accountRes = await fetch(`/account/me.json`).then((res) => res.json()).catch(console.error);

// routes/account/me.json/+server.ts
export const GET: RequestHandler = async ({ request }) => {
// This function never gets called
})

[rkurbatov]

The same here but on Chrome 109 for Linux. Firefox works, though Chrome 109 on MacOS also works fine. That's pretty annoying :)

The project is quite large.

Runing with --debug option doesn't show any errors, it just goes sequentially across multiple project files and then just stops at some time.

Upd. Just tried Chrome 110 Beta on Linux with the same results.

[rkurbatov]

Based on this comment - has anyone tried using an older version of node (16.15 instead 18.x) - this could be a possible solution for the infinite pending requests in the network tab: #7620 (comment)

I tried versions 14, 16 and 18. It looks like Chrome problem, not the Node problem because it works on FF on all Node versions but hangs in Chrome only.

[rkurbatov]

So I found the fix (at least to my problem). This problem is similar to this one: https://github.com/vitejs/vite/issues/5310

In case you have a big project with plenty of files Chrome demands more file descriptors than system allows (1000 by default). I have Ubuntu Linux, so using ulimit -Sn didn't work for me. Like, it updates the amount of descriptors but that has to be done permanently as Chrome doesn't use it.

so, for Ubuntu Linux you have to add line * - nofile 65536 (or whatever amount of opened files you need) to the file /etc/security/limits.conf and reboot.

For Arch Linux they say to add DefaultLimitNOFILE=65536 line to both /etc/systemd/system.conf and /etc/systemd/user.conf file. Didn't check that.

Upd. LOL. Just figured out that DefaultLimitNOFILE can be applied to Ubuntu as also but it simply doesn't work, so limits.conf is the only working solution there. Will provde PR.

[ximus]

Weird stuff. Using SvelteKit as well.

• vite dev then request from Chrome => hangs
• vite dev then request from Firefox => works, subsequent request from Chrome => works

wtfnode shows that the socket from chrome is never closed, just hangs. But there are no node hooks waiting except for the vite connect app server.

I can see the commit where this behaviour begins in my codebase. But nothing stands out. Here's the patch if anyone is curious, but it's just business logic changes relevant to my app (warning: large commit) (ignore the ruby code).

I'll have to keep looking.

UPDATE: just showed up again randomly. This time firefox requests don't help. UPDATE 2: Now the firefox request thing works again

[rkurbatov]

I'll have to keep looking.

Did you try what I suggested? Seems like that's a known issue but proposed fix doesn't work.

[roligheten]

so, for Ubuntu Linux you have to add line * - nofile 65536 (or whatever amount of opened files you need) to the file /etc/security/limits.conf and reboot.

Thank you @ximus This solved the issue for me :1st_place_medal:

[hanszoons]

I am not on Linux, but on a Mac and Firefox has the same issue. In what way does #11959 close this?

[rkurbatov]

@hanszoons did you try something like this - https://superuser.com/questions/302754/increase-the-maximum-number-of-open-file-descriptors-in-snow-leopard ?

The reasons look pretty same, hanging requests on big projects with huge amount of files and seems like caused by not enough amount of descriptors on different browsers (though FF and Chrome seems like treating it differently).

[hanszoons]

Yes I tried that before opening the issue (as it already was in the vite docs). I have many imports, but from only a few files (about 20-30). That's not a big project in terms of file descriptors.

Just tried it again, same predictable hang when I edit an imported function.

[wtachau]

I am also not on Linux, and seeing this same issue as recently as yesterday on SvelteKit 1.5.6 and vite 4.1.1. Please re-open this issue.

[fc]

I found what looks like a solution that works for me but it would be good to get validation or improvements from this approach. My previous looking into the root cause of this it seemed like it was an issue with node's http. Well, someone wrote undici which is an HTTP client written from scratch. @fastify/http-proxy is a module that uses undici under the hood. server.proxy settings remain in vite.config and nothing special is really required.

const fs = require("fs");
const path = require("path");
const proxy = require("@fastify/http-proxy");

const serverDirectory = "/path/to/ssl";
const fastify = require("fastify")({
  logger: false,
  http2: true,
 /* enable if you need it
  https: {
    key: fs.readFileSync(path.join(serverDirectory, "proxy.key")),
    cert: fs.readFileSync(path.join(serverDirectory, "proxy.cer")),
  }, */
});

fastify.register(proxy, {
   // change to https if you need it
  upstream: "http://localhost:3000",
  prefix: "/",
  // enables vite's HMR, might also need to update server.clientPort in vite config
  // https://vitejs.dev/config/server-options.html#server-hmr
  websocket: true, 
});

fastify.server.on("secureConnection", (sock) => {
  sock.on("error", (err) => {
    console.log("Socket error", err);
  });
});

fastify.listen({ port: 3001 }, (err, address) => {
  if (err) {
    console.log("ERR:", err);
  }
});

Feel like there must be some http setting that would work but no idea what that would be as things I tried didn't work. If you google around, you'll find people who run into the issue with pending requests it could be related to a request that is hanging open and not closed. Could there be a catch or error event handler that is swallowing what would normally be an error and silently failing? Could there be a middleware that is encountering an unexpected situation and just returning early?

[HynekS]

I had the same problem (pretty frustrating), and as I figured out, the issue was that I mistakenly nested a React component inside itself, which probably resulted in infinite recursion. (I'm not implying that other people's problems are caused by their own bugs! just my experience).

[maxsalven]

@fc can you explain more how to set up the fastify proxy to replace the default vite one?