Because it uses Java it seems not possible to make a reproduction on Stackblitz, it tries to compile using node-gyp.
I can provide a repo if needed.
For a repro see below.
Describe the bug
Changing a server api route and saving it causes a HMR to occur after which the API server crashes.
Additional context
This is the last part of DEBUG=* npm run dev where the nuxt api dev server is ready to accept requests. The next few lines are from a request to the /api/version endpoint which returns the version of the jdbc.jar that is currently loaded.
Then I edit and save the version endpoint, add an ! to the return text, and the HMR is triggered but then the dev server seems to internally crash because redoing the curl request leads to the unhandledRejection.
I tried debugging the devserver and it seems that cleaning up the worker thread is where things go haywire but I don't know how to debug that part.
The cause of the problem is probably the Java instance that is started but that shouldn't lead to crashes IMHO :-)
Its probably not related to the specific jdbc driver that I use, sqlite3 jdbc driver has the same problem and that also excludes network problems as a probable cause.
Logs
ℹ Vite server warmed up in 1557ms 2:10:00 PM
[nitro] types:extend: 0.015ms 2:10:00 PM
✔ Nuxt Nitro server built in 937 ms nitro 2:10:01 PM
[nitro] compiled: 0.351ms 2:10:01 PM
[nuxt] build:done: 2.270s 2:10:01 PM
winston:create-logger: Define prototype method for "error"
[nitro] dev:reload: 243.772ms 2:10:01 PM
winston:create-logger: Define prototype method for "warn"
winston:create-logger: Define prototype method for "info"
winston:create-logger: Define prototype method for "http"
winston:create-logger: Define prototype method for "verbose"
winston:create-logger: Define prototype method for "debug"
winston:create-logger: Define prototype method for "silly"
custom
Custom driver
> Nitro Start (47ms)
connect:dispatcher <anonymous> : /api/version +2m
connect:dispatcher viteTimeMiddleware : /api/version +0ms
connect:dispatcher viteCachedTransformMiddleware : /api/version +0ms
connect:dispatcher viteBaseMiddleware : /api/version +1ms
connect:dispatcher viteHMRPingMiddleware : /api/version +0ms
connect:dispatcher viteServePublicMiddleware : /api/version +0ms
connect:dispatcher handle : /api/version +0ms
connect:dispatcher viteTransformMiddleware : /api/version +0ms
vite:resolve 0.26ms /__skip_vite/api/version -> null +2m
connect:dispatcher viteServeRawFsMiddleware : /api/version +1ms
connect:dispatcher viteServeStaticMiddleware : /api/version +0ms
connect:dispatcher viteErrorMiddleware : /api/version +0ms
send stat "/home/PUZZLE-IT/joop/dev/gbbeheer-nuxt3/.nuxt/dist/client/api/version" +0ms
send stat "/home/PUZZLE-IT/joop/dev/gbbeheer-nuxt3/public/api/version" +2ms
[nitro-runtime] request: 0.285ms
vite:time 16.16ms /api/version +0ms
[nitro-runtime] beforeResponse: 0.013ms
[nitro-runtime] afterResponse: 0.029ms
[nuxt] builder:watch: 1.153ms 2:11:49 PM
vite:hmr [file change] server/api/version.ts +2m
vite:hmr [no modules matched] server/api/version.ts +1ms
✔ Nuxt Nitro server built in 220 ms nitro 2:11:49 PM
[nitro] compiled: 0.405ms 2:11:49 PM
[nitro-runtime] close: 0.057ms
ERROR [unhandledRejection] connect ECONNREFUSED 127.0.0.1:42271 2:12:53 PM
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1595:16)
Environment
Nodejs 20.10.0, relevant part of my package.json
Reproduction
Because it uses Java it seems not possible to make a reproduction on Stackblitz, it tries to compile using node-gyp. I can provide a repo if needed. For a repro see below.
Describe the bug
Changing a server api route and saving it causes a HMR to occur after which the API server crashes.
Additional context
This is the last part of
DEBUG=* npm run dev
where the nuxt api dev server is ready to accept requests. The next few lines are from a request to the/api/version
endpoint which returns the version of the jdbc.jar that is currently loaded. Then I edit and save the version endpoint, add an ! to the return text, and the HMR is triggered but then the dev server seems to internally crash because redoing the curl request leads to the unhandledRejection.I tried debugging the devserver and it seems that cleaning up the worker thread is where things go haywire but I don't know how to debug that part.
The cause of the problem is probably the Java instance that is started but that shouldn't lead to crashes IMHO :-) Its probably not related to the specific jdbc driver that I use, sqlite3 jdbc driver has the same problem and that also excludes network problems as a probable cause.
Logs