Per-turn Workers leak an event loop and ~0.8 MB each on Bun < 1.4 (OpenCode V1 up to 1.19.3) #776

Environment

• Magic Context 0.49.4, OpenCode 1.19.1 (V1) built with Bun 1.3.14 (upstream pins bun@1.3.14 through 1.19.3), Linux x64 (WSL2)

What

Every short-lived Worker Magic Context starts and terminates leaks its event loop on Bun 1.3.14: 3 file descriptors ([eventpoll], [eventfd], [timerfd]) plus about 0.7–0.85 MB of native memory. GC never frees either. We measured about four per turn. The Workers the bundle creates per job are auto-search, the message worker, compaction-marker candidates and session warmup.

Measured

• 15 long-running opencode serve processes (0.2–31 h old) held 26,404 leaked loops. Across processes, native memory (unnamed anonymous mappings) grew 0.65–0.88 MB per leaked loop. Example: one 31 h server had 8,113 leaked loops and 5.3 GB of native memory, out of 7.1 GB total RSS + swap.
• Controlled test on one server: 15 one-line turns with no tools gave +61 leaked loops and +52 MB of native memory, measured after Bun.gc(true).
• The same 15 turns on the same OpenCode code rebuilt with Bun 1.4.2: 0 leaked loops, +15 MB.

Count per process: ls -l /proc/<pid>/fd | grep -c eventpoll.

Repro (Bun only)

// worker.js: self.onmessage = (e) => self.postMessage(e.data)
import { readdirSync, readlinkSync } from "fs"
const loops = () => readdirSync("/proc/self/fd").filter((f) => { try { return readlinkSync(`/proc/self/fd/${f}`).includes("eventpoll") } catch { return false } }).length
for (let i = 0; i < 200; i++) {
  const w = new Worker(new URL("./worker.js", import.meta.url).href)
  await new Promise((r) => { w.onmessage = r; w.postMessage(i) })
  w.terminate()
}
console.log("eventpoll fds:", loops()) // Bun 1.3.14: 201, Bun 1.4.2: 1

Suggestion

Keep these Workers alive and reuse them instead of creating one per job. Bun's own advice is not to terminate Workers (oven-sh/bun#15964). Alternatively, document that OpenCode builds on Bun < 1.4 (V1 up to 1.19.3) leak memory on every turn. OpenCode 1.19.4 pins bun@1.4.4; we have not tested that release.