ERROR [unhandledRejection] read ECONNRESET #23832
Comments
|
Would you be able to provide a reproduction? 🙏 More infoWhy 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 prioritize it based on its severity and how many people we think it might affect. If 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 A public GitHub repository is also perfect. 👌 Please ensure that the reproduction is as minimal as possible. See more details in our guide. You might also find these other articles interesting and/or helpful: |
|
Do you have a custom HMR port? Is |
|
I believe this one is extremely difficult to reproduce and perhaps an issue somewhere with the local env setup. This is one of the reasons I have not reported this myself. Even after completely reinstalling node pnpm this issue still occurs. However @castrogarciajs perhaps this will help as a short term workaround ✔ Nitro built in 6575 ms nitro 11:52:46 PM
ℹ Vite client warmed up in 14274ms 11:52:47 PM
(node:80030) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification.
(Use `node --trace-warnings ...` to show where the warning was created)
ERROR [unhandledRejection] connect ETIMEDOUT 127.0.0.1:55605 11:53:36 PM
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1555:16)This port will of course change every time you restart the dev server. I think this perhaps relates to layers and directed at more complexed nuxt projects. Environment
|
|
I'm experiencing the same issue. I'm using a package called |
|
I forgot to mention the most important part: The code will work the first time I start the server, but it freezes whenever I make a change and save it. However, it only freezes when I make a change on the server-side, not on the client-side. It is extremely annoying to Ctrl C and restart every time I make a change. |
|
I've successfully reproduced the problem in a minimal project. However, it's important to note that the Please let me know your GitHub usernames so that I can invite you to the repository. I've already invited danielroe to the repository, which you can find here. If you have the time, we could arrange a screen-sharing session for further assistance. I also attempted to address the issue by adding the following code snippet to vite: {
optimizeDeps: {
exclude: ['node-rfc'],
},
}One more challenge I encountered is that when I run |
|
Hello, It is impossible to make a reproduction, because it is an error that happens during development and I cannot capture the exact moment of the error. I just have to close everything again. I don't have a custom port, I work with the default nuxt configuration. |
|
I think this happens in projects with db connection, I get the same error sometimes. Does everyone have a db connection in the project? |
|
@productdevbook I don't think this issue is related to the db connection. Most of our endpoints use This was working up until v3.7.0 so I suspect it has something to do with the Nitro 2.6 update. import type { H3Event } from 'h3'
import { getCookie } from 'h3'
const baseUrl = process.env.NUXT_APP_HUB_BASE_URL
interface INitroApiOptions {
event: H3Event
endpoint: string
action?: string
requiresAuth?: boolean
method?: any
contentType?: string
query?: any
}
export default function useNitroApi(options: INitroApiOptions, data?: any): Promise<any> {
const {
event,
endpoint,
action,
requiresAuth = false,
method = 'GET',
contentType = 'application/json',
query = {},
} = options
const headers: any = {
Accept: contentType,
'Language-Locale': getCookie(event, 'i18n_redirected'),
'Content-Type': contentType,
}
if (requiresAuth) {
headers.Authorization = `Bearer ${getCookie(event, 'token') || ''}`
}
const opts: any = {
method,
headers,
}
if (!['show', 'index', 'destroy'].includes(<string>action)) {
opts.body = data ? JSON.stringify(data) : undefined
opts.query = query
}
return $fetch(`${baseUrl}${endpoint}`, opts)
} |
I also had this error in version 3.7 and I was not interested because I was suspicious of the db. now 3.8 has the same error. |
|
@danielroe Could the issue be due to nitro changing to unjs/httpxy? This does seem to be around the same date 3.7.0 was released. Also this does seem to be where the error is coming from 👀 |
|
This was the issue and I have found a solution which works perfectly 😁 nitro: {
devProxy: {
host: 'localhost',
},
}, |
It doesn't work for me (I get problem every time I update the server-side code, 100% reproducible) :/
|
|
@unitythemaker Are you using localhost with a default port? @productdevbook @castrogarciajs did my solution work for you guys? |
|
@adam-code-labx My version is 20.9.0, I use default port of nuxt |
Ok and you still get an error after adding this to your nuxt config? nitro: {
devProxy: {
host: 'localhost',
},
}, |
Yeah probably it is because node-rfc and some complicated thing happening with hmr and it breaks from it. However, I am not sure because this is just a guess. |
|
If you ever wanted to check out my minimal reproduction, I gave you access at here. |
I recommend you update node js to version 20 |
I switched to Node v20 now. It is still the same. |
|
|
|
@productdevbook ummm thats strange overriding nitro devProxy should have worked for you 🤔 export default defineNuxtConfig({
// ... nuxt config
nitro: {
devProxy: {
host: '127.0.0.1',
},
},
}) |
This seems to have solved it for me. Thank you very much! |
|
I have the same problem This does not solve my problem |
|
same，I get problem every time when i refresh browser, 100% reproducible |
Yes, HMR never works for me due to this error. I always refresh manually during development. |
|
@danielroe Sorry for the ping, I'm not sure if the following issue is related to that one, but I'm getting ...
app: {
head: {
charset: 'utf-8',
viewport: 'width=device-width, initial-scale=1',
script: [
{
'hid':'stripe',
'src':'https://js.stripe.com/v3/',
'defer': true
}
]
},
},3- Interact with the API from a page: <script setup>
let isStripe = () => {
if (Stripe) {
return new Stripe('pk_test_TYooMQauvdEDq54NiTphI7jx');
}
return false;
};
</script>
<template>
<div>
<h1 v-if="isStripe()">ok</h1>
<h2 v-else>No</h2>
</div>
</template>P.S. The app will continue to work while the lib is loading, but looks like Nitro is detecting an error. |
|
@bitsnaps That's not valid code on the server. Wrap it in |
|
Thanks! I thought ClientOnly was the proper way to check for that, but that's for the client side only, we need some time to get used to write Nuxt on the server! I've just came across your note here to grasp that point. |
|
@danielroe could we just have an update, will you or anyone from the core team look at this anytime soon or should the community find a workaround on their own? |
|
I'm still having issues with this after upgrading. Really frustrating. First Electron CLI pnpm nuxi info |
Same error:
|
I think most of these issues are related to nuxi -> nuxt cli transition that happened with 3.7. I have been having good luck staying back with 3.7.3 (not sure if I could go update further by staying on nuxi 3.8.4) by means of the below overrides in my package.json: While this is not really the solution to this issue, given the wait, if you could, give it a shot. Obviously, this is a trade-off as this will miss other bug fixes that came in the later releases. |
|
Please note, the following are my observations, thoughts, and speculations. From my observations, there are two distinct problems at play here, neither of which are directly related to Nuxt itself, but rather to NitroPack or the compiler used for Nitro. I was unable to reproduce these issues by merely updating client-side code. However, the behaviors of Nitro and Nuxt seem to diverge significantly when these bugs occur. In Nitro, the server continues to serve requests as usual but stops reloading, running the pre-bug code. In Nuxt, requests stop receiving responses, and a listener keeps the client alive indefinitely, preventing even the Nuxt starting page from loading.Problem 1: Race ConditionThe race condition issue appears more frequently in larger projects due to the time it takes to build the Nitro server. In a medium-scale project, if you press To reproduce this, I created a directory named Problem 2: Incompatible ModulesThe second issue occurs when using incompatible modules, such as Additional ObservationsThere seems to be some server-client interaction between the compiler and the running program to perform HMR or a similar process, though this area is less clear to me. The build server likely encounters a fatal error and crashes, leading to the client receiving a Collaboration Request If others could confirm or reject these observations, we can work together to pinpoint the exact issues and potentially develop a solution. Your feedback and insights are crucial for us to tackle this problem collaboratively and effectively. Let's pool our knowledge and efforts to fix this issue. Why this is important for me?This issue is becoming increasingly critical for me as our projects grow. Particularly because we use Nuxt UI, which renders pages very slowly for some reason. Adding this crashing problem to the mix makes it nearly unbearable to continue developing our projects beyond a certain point. I literally need to wait around 30 seconds between each server-side change, which significantly hampers our development process.Thank you for your understanding and cooperation. |
|
I have been maintaining few reliable reproductions for this [unhandledRejection] type errors in the nuxt/cli repo from 3.7.4 onwards. Please refer to these: Lately in nuxt/cli#425, I have noticed HMR not establishing a connection at all when a vite plugin is added using the addVitePlugin nuxt kit utility. As I previously mentioned, all these unhandledRejection E-type errors all surfaced only after the nuxi->nuxt/cli transition. This should have ideally been released in an experimental way,so the community could have test and avoided all these issues instead of pushing it on us. Given the random nature of these errors, even ecosystem ci wouldn't have picked these up. It would be great to have these errors sorted before going another major version. |
|
Thank you @TechAkayy. @pi0 and I have discussed reverting the current behaviour in nuxi. |
|
I ran into this problem with a mono-repository that I just refactored in multiple layers and it only happens when I change code in the It makes developing a nightmare as one has to restart Is there a way to debug this? |
npx nuxi@latest upgrade |
|
Still getting the problem even with Each time I save a /server/api/*.ts file: Nuxi version: 3.12.0 logs ERROR [unhandledRejection] socket hang up 11:49:45 AM
at Socket.socketOnEnd (node:_http_client:526:23)
at Socket.emit (node:events:532:35)
at endReadableNT (node:internal/streams/readable:1696:12)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
ERROR [unhandledRejection] connect ECONNREFUSED 127.0.0.1:57197 11:50:11 AM
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1607:16) |
|
Hi again, I fixed it with disabling all prerender: export default defineNuxtConfig({
...
routeRules: {
"/": { prerender: false },
"/api/search.json": { prerender: false },
"/docs": { redirect: "/docs/getting-started", prerender: false },
},
...
}); |
now i found only 2 solutions.
Well, we are still waiting for the next version. I really hope that this will be fixed in nuxt@4 |
For me the issue was fixed with nuxt/content#2691 |
how would you use bun instead of node |
Thanks, that actually makes it work, which is amazing:)) |
|
We are also facing this issue in a monorepo with a payload cms backend, a nuxt frontend and a nuxt module for components. Nothing overly complicated, but half the time the frontend simply won’t work. None of the workarounds posted here seem to have any impact. We are getting all sorts of errors, at random times. Sometimes after navigating, sometimes after a hard refresh. It’s basically impossible to work on the project at all in this state. 
I’d be happy to give the Nuxt team access to our repo and help set up a local environment to reproduce the problems we are facing. @danielroe @pi0 please let me know if this would be of interest! |
|
One source of the problems we are facing is an icon component that pulls in a large icon library with <template>
<icon-component class="icon-renderer" />
</template>
<script lang="ts" setup>
import { defineAsyncComponent, type ComponentPublicInstance } from 'vue'
import { filename } from 'pathe/utils'
interface IconRenderer {
name: string
weight?: 400 | 500
}
const props = withDefaults(defineProps<IconRenderer>(), {
weight: 400,
})
const IconComponent = defineAsyncComponent({
loader: async () => {
const glob = import.meta.glob<{ default: ComponentPublicInstance }>(
`../assets/icons/*-(400|500).svg`,
{
eager: true,
}
)
const icons = Object.fromEntries(
Object.entries(glob).map(([key, value]) => [filename(key), value.default])
)
const name = `${props.name}-${props.weight}`
const icon = icons[name]
return icon
},
})
</script> |
and others
Environment
Reproduction
Sorry, I can't share code due to corporate law... I hope you understand. 🙏
Describe the bug
When I am programming for a long time nuxt gives me that server error apparently and it is usually tedious because I have to start everything again
Vite server hmr 17 files in 10811.276ms ERROR [unhandledRejection] connect ECONNREFUSED 127.0.0.1:41119 10:57:18 AM at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1555:16)Additional context
No response
Logs
Vite server hmr 17 files in 10811.276ms ERROR [unhandledRejection] connect ECONNREFUSED 127.0.0.1:41119 10:57:18 AM at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1555:16)The text was updated successfully, but these errors were encountered: