fix: clean up previous runtime on Bun HMR reload #6047
Conversation
When using `bun --hot`, each module re-evaluation creates a new program causing memory leaks. Here we ensure only one active runtime exists at any time, and cleanup on each hot reload.
🦋 Changeset detectedLatest commit: c3b9780 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
I'm not sure why we need keepAlive timer here. I've used this version of |
| if (hmrState.keepAlive) { | ||
| clearInterval(hmrState.keepAlive) | ||
| } | ||
| hmrState.fiber.unsafeInterruptAsFork(hmrState.fiber.id()) |
There was a problem hiding this comment.
Will probably need to wait for the previous fiber to exit before starting another one, in the case there are long running finalizers that could hold ports open.
There was a problem hiding this comment.
When bun is --hot, Bun automatically updates server handles on subsequent runs so there's no port holding. My initial implementation waited for previous program to finalize but that caused intermissions in-between, similar to what happens when --watch is used.
Since --hot is explicit and opt-in, I think current behavior makes sense. I think even React hot reloading via react-fast-refresh is executing new tree and running cleanup after vdom compare.
For the case where nothing will keep the event loop busy. In node this would exit the program immediately, not sure about bun runMain(Effect.async<void>(() => {})) |
|
Just did a test on Bun and it does indeed exits without keep alive timer. Make sense since it aims for full node compat. In my codebase where I tested it without that timer I must have had some dangling timers. Also added changeset and a comment about interruption behavior. |
2 participants
When using
bun --hot, each module re-evaluation creates a new program causingmemory leaks.
Here we ensure only one active runtime exists at any time by cleaning up
on each hot reload.