You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: close all open handles on dispose to prevent process hangs
6
+
7
+
Several resources were not being properly cleaned up during `Miniflare.dispose()`, which could leave the Node.js event loop alive and cause processes (particularly tests using `node --test`) to hang instead of exiting cleanly:
8
+
9
+
- The internal undici `Pool` used to dispatch fetch requests to the workerd runtime was not closed. Lingering TCP sockets from this pool could keep the event loop alive indefinitely.
10
+
-`WebSocketServer` instances for live reload and WebSocket proxying were never closed, leaving connected clients' sockets open.
11
+
- The `InspectorProxy` was not closing its runtime WebSocket connection, relying on process death to break the connection.
12
+
-`HyperdriveProxyController.dispose()` had a missing `return` in a `.map()` callback, causing `Promise.allSettled` to resolve immediately without waiting for `net.Server` instances to close.
13
+
-`ProxyClientBridge` was not clearing its finalization batch `setTimeout` during disposal.
14
+
-`InspectorProxyController.dispose()` was not calling `server.closeAllConnections()` before `server.close()`, so active HTTP keep-alive or WebSocket connections could prevent the close callback from firing.
fix: ensure esbuild context is disposed during teardown
6
+
7
+
The esbuild bundler cleanup function could race with the initial build. If `BundlerController.teardown()` ran before the initial `build()` completed, the `stopWatching` closure variable would still be `undefined`, so the esbuild context was never disposed. This left the esbuild child process running, keeping the Node.js event loop alive and causing processes to hang instead of exiting cleanly.
8
+
9
+
The cleanup function now awaits the build promise before calling `stopWatching`, ensuring the esbuild context is always properly disposed.
0 commit comments