Stuck or slow pending requests

[Magnuti]

Describe the bug

When using the Vite dev server some requests seems to be stuck in a pending state, or they take over a minute to complete. The debug logs does not indicate that this is an issue other than that they take over a minute to complete.

What's particularly odd is that the affected file in this case, uiData.js, is quite small. So, it's puzzling why it's taking so long to load. All other requests only take a few milliseconds.

This is a relevant issue but it's conversation is locked #5310

I have already tried to increase the open file limit without any success.

$ ulimit -n    
10496

Reproduction

I am unable to provide a reproduction without exposing a company's codebase.

Steps to reproduce

Have an existing React project
Install packages with yarn with yarn
Start the dev server with vite
Open localhost
Open dev tools in the browser

System Info

System:
  OS: MacOS Sonoma 14.1
  Chip: Apple M3 Pro
  Memory: 36 GB
  Container: No
  Shell version: zsh 5.9 (x86_64-apple-darwin23.0)
Binaries:
  Node: v18.19.1
  Yarn: 1.22.21
Browsers:
  Both Chrome and Opera seems affected
Relevant npm packages:
  "vite": "^5.2.8"
  "react": "18",
  "typescript": "4.4.4",
  "@loadable/component": "^5.16.3",

### Used Package Manager

yarn

### Logs

<details>
<summary>Click to expand!</summary>

```shell
vite:cache [304] /src/views/financials/evictions/evictions-data-table/index.jsx +1ms
vite:time 0.17ms /src/views/financials/evictions/evictions-data-table/index.jsx +1ms
vite:cache [304] /src/views/financials/evictions/evictions-summary/index.jsx +0ms
vite:time 0.07ms /src/views/financials/evictions/evictions-summary/index.jsx +0ms
vite:cache [304] /src/views/financials/evictions/graphql/getEvictionsSummary.gql?import +0ms
vite:time 0.11ms /src/views/financials/evictions/graphql/getEvictionsSummary.gql?import +1ms
vite:cache [304] /src/views/financials/evictions/helpers/uiData.js +1m
vite:time 0.08ms /src/views/financials/evictions/helpers/uiData.js +1m
vite:cache [304] /src/views/financials/evictions/eviction-filters/index.jsx +0ms
vite:time 0.03ms /src/views/financials/evictions/eviction-filters/index.jsx +0ms
vite:cache [304] /src/views/financials/evictions/eviction-filters/EvictionFiltersForMobile.jsx +8ms
vite:time 0.09ms /src/views/financials/evictions/eviction-filters/EvictionFiltersForMobile.jsx +8ms
vite:cache [304] /src/views/financials/evictions/eviction-filters/EvictionSortFilterForMobile.jsx +0ms
vite:time 0.02ms /src/views/financials/evictions/eviction-filters/EvictionSortFilterForMobile.jsx +0ms

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• 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.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[Allihol]

same question！
so wried that when this happen, it must take 1.1min to finish。 why 1.1min......
我也遇到了这个问题，设备是mbp 2020， 系统是Monterey12.3.1。
偶现通过devServer调接口时非常慢，但是每次1.1min后又会响应。
通过查看Nginx发现请求根本没有到我配的proxy的target上，这1.1min就是消耗在我的本机。
而且相同的代码和配置，换一台设备就好了......
如果这是bug，希望能尽快解决，很影响工作......

[Magnuti]

Unfortunately I do not speak Chinese @Allihol, but Google translate was helpful:

I also encountered this problem, the device is mbp 2020, and the system is Monterey12.3.1.
Occasionally, it is very slow when adjusting the interface through devServer, but it will respond after 1.1 minutes each time.
By checking Nginx, I found that the request did not go to the target of the proxy I configured at all, and these 1.1 minutes were consumed on my local machine.
And with the same code and configuration, just change another device...
If this is a bug, I hope it can be solved as soon as possible, it will affect the work...

I also use an Nginx proxy.

You wrote that:

I found that the request did not go to the target of the proxy I configured at all

Can you confirm that Nginx did not receive the request until 1.1 minute @Allihol? Or did the request halt at the Nginx proxy for 1.1 minute?

[Allihol]

Thank you for your reply.

This project accesses the server through Nginx forwarding. I first request the frontend static resource server and then forward it to the corresponding backend service through proxy_pass.

Can you confirm that Nginx did not receive the request until 1.1 minute
I checked the Nginx logs, and I confirmed that Nginx did not receive the request until 1.1 minutes later.
Strangely, the same code and configuration do not have this problem on other devices.
Moreover, when I change the proxy's target to the domain name of another environment, the problem does not occur (there are multiple test environments).

[Magnuti]

I checked the Nginx logs, and I confirmed that Nginx did not receive the request until 1.1 minutes later.

So it seems that the requests stalls in the Vite dev server.

[Magnuti]

@Allihol do you also use loadable?

[Magnuti]

Relevant but not fixed by #11468

[cross32768]

I am experiencing the same issue.

It occurs when I set up a proxy in vite.config.ts to send requests from the frontend to the backend and access localhost:5173.
However, it does not occur when the frontend and backend are connected directly; it only seems to happen when there is a proxy in between, such as nginx or OAuth2-proxy.

My environment is Mac, and despite setting ulimit to a sufficiently large value (over 1,000,000) as suggested in past issues, the problem persists.

[delarre-reve]

Also running into this, hard to create a reproduction environment but the basic desired setup is an nginx server using proxy_pass to a vite dev server. In this scenario sometimes many files can end up in pending request state for 30+ seconds or more, and sometimes timeout entirely.

[pthieu]

I'm having what could be the same issue
I've set up a custom express server to serve a remix UI and have a vite dev server for HMR following remix's quickstart: https://remix.run/docs/en/main/start/quickstart

Tried node 22.6.0 and 18.18.2 and both will hang.

I'm able to simple set my NODE_ENV between using production or not and can reproduce the issue.

Maybe this can serve as a smaller reproduction codebase.

[dxu-reve]

Just circling back from Reve, what worked for us was the following configuration change in nginx, it seems the connection keep-alive header that browsers add can cause an upstream hang. May need some additional configuration to keep HMR working.

proxy_set_header Connection "";

[Magnuti]

Setting proxy_set_header Connection ""; does not fix the issue for me.