Node http.createServer can 100% CPU after day uptime in Bun 1.3.13 and 1.4.0 #32600

What version of Bun is running?

1.4.0-canary.1+9d000561c

What platform is your computer?

Linux 6.19.14+deb14-amd64 x86_64 unknown

What steps can reproduce the bug?

I do not currently have a minimal standalone reproduction.

This occurs in a real server application: https://github.com/L3P3/rtjscomp

The app uses Node-compatible HTTP server APIs via http.createServer.

Observed pattern:

1. Run the server under Bun.
2. After long uptime (usually after half a day), one CPU core jumps to ~100% and stays there permanently.
3. During the bad state, profiler samples are dominated by:
   • processTicksAndRejections
   • internal:fixed_queue.shift
4. Calling actions.http_stop() immediately drops CPU from ~100% to ~5%.
5. Calling actions.http_start() afterwards keeps CPU around ~6% and the server remains in the normal state.
6. A new profile taken after restarting only the HTTP server no longer shows the queue flood. Instead it shows expected work such as:
   • normal HTTP response path (node:_http_outgoing)
   • DNS service subprocess spawn path (node:child_process) from ip_get_local() / exec("ip addr show")

What is the expected behavior?

The server should return to idle normally and should not get stuck permanently draining async/tick/microtask queues.

Restarting only the HTTP server should not be necessary to clear a bad internal state.

What do you see instead?

After long uptime, Bun enters a bad state where one CPU core stays at ~100% permanently.

In that state, profiler output is dominated almost entirely by:

• processTicksAndRejections
• internal:fixed_queue.shift

Stopping the HTTP server clears the high CPU condition immediately, and starting it again does not immediately reintroduce the problem.

This was originally observed on 1.3.13 and still occurs on 1.4.0.

Additional information

Why this seems Bun-specific:

• The same app under Node.js does not reproduce this behavior.
• Hot frames are Bun / Node internals, not dominated by application functions.
• The app uses http.createServer in Node-compat mode.

My current conclusion is that this is a stuck or looping async request state in Bun's Node-compat event loop path, not steady-state application logic.

When it happens, Bun appears to repeatedly drain tick/microtask queues and never returns to idle.

Resetting the HTTP server clears the stuck connection/request state, which immediately removes the flood.

Probable trigger class:

• long-lived or stale HTTP connections / handlers that do not settle cleanly
• possibly streaming or event-style endpoints, or dynamic template execution that can keep a request open

Current workaround:

• call actions.http_stop()
• then call actions.http_start()

That clears the state.