core: CPU-heavy plugin setup and full-scope teardown starve the shared event loop #55272

Activity

1. opencode-agent commented on Oct 14, 2026

   

   opencode-agentBot

   on Oct 14, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report. I reproduced this on the latest dev (73517183b) at the core plugin service level.

   The script below is a bun test for packages/core. It activates 30 plugins that each busy-wait 80 ms and runs a 5 ms setInterval in the same process to measure gaps:

   • Teardown: each plugin adds a finalizer that busy-waits, then Plugin.Service.close closes the parent scope. Closing took about 2.4 s, and the timer fired only 3 times (longest gap 2401 ms).
   • Setup: each plugin's setup busy-waits. Activation took about 2.4 s, with a longest timer gap of 2403 ms.

   The gap is about 30 × 80 ms, so other work in the process doesn't run between plugins, on either path. I didn't run the 2.0.28 release itself, but the plugin lifecycle code in v2.0.28 is identical to dev. I measured this inside the core plugin service, not through the HTTP server or the event stream.

   Reproduction script (plugin-starve-repro.test.ts)

   // Repro for anomalyco/opencode#55272: plugin cleanup/setup monopolize the event loop.
   import { expect } from "bun:test"
   import { Effect, Exit } from "effect"
   import { Plugin } from "@opencode/core/plugin"
   import { testEffect } from "./lib/effect"
   import { PluginTestLayer } from "./plugin/fixture"
   
   const it = testEffect(PluginTestLayer)
   const N = 30
   const BUSY = 80
   const busy = () => {
     const end = performance.now() + BUSY
     while (performance.now() < end) {}
   }
   
   function monitor() {
     let last = performance.now()
     let maxGap = 0
     let ticks = 0
     const t = setInterval(() => {
       const now = performance.now()
       maxGap = Math.max(maxGap, now - last)
       last = now
       ticks++
     }, 5)
     return {
       stop: () => {
         clearInterval(t)
         maxGap = Math.max(maxGap, performance.now() - last)
         return { maxGap: Math.round(maxGap), ticks }
       },
     }
   }
   
   it.live("teardown: timer progress while closing plugin scope", () =>
     Effect.gen(function* () {
       const plugins = yield* Plugin.Service
       yield* plugins.activate(
         Array.from({ length: N }, (_, i) => ({
           id: `p${i}`,
           revision: "1",
           effect: () => Effect.addFinalizer(() => Effect.sync(busy)),
         })),
       )
       yield* Effect.sleep("50 millis")
       const m = monitor()
       const start = performance.now()
       yield* plugins.close(Exit.void)
       yield* Effect.promise(() => new Promise((r) => setTimeout(r, 20)))
       const r = m.stop()
       console.log(`[teardown] ${N} plugins x ${BUSY}ms: close took ${Math.round(performance.now() - start)}ms, max timer gap ${r.maxGap}ms, ticks ${r.ticks}`)
       expect(r.maxGap).toBeLessThan(BUSY * 3)
     }),
   )
   
   it.live("setup: timer progress while activating CPU-heavy plugins", () =>
     Effect.gen(function* () {
       const plugins = yield* Plugin.Service
       const m = monitor()
       const start = performance.now()
       yield* plugins.activate(
         Array.from({ length: N }, (_, i) => ({
           id: `s${i}`,
           revision: "1",
           effect: () => Effect.sync(busy),
         })),
       )
       yield* Effect.promise(() => new Promise((r) => setTimeout(r, 20)))
       const r = m.stop()
       console.log(`[setup] ${N} plugins x ${BUSY}ms: activate took ${Math.round(performance.now() - start)}ms, max timer gap ${r.maxGap}ms, ticks ${r.ticks}`)
       expect(r.maxGap).toBeLessThan(BUSY * 3)
     }),
   )

   Run it: bun plugin-starve-repro.test.ts
2. opencode-agent

   added

   reproduced

   on Oct 14, 2026
3. mradwankhalil commented on Oct 23, 2026

   

   mradwankhalil

   on Oct 23, 2026

   ContributorAuthor

   More actions

   Thanks for the independent reproduction. The roughly 2.4 s timer gaps on both setup and teardown are core-plugin-service evidence, not an HTTP-server measurement. The proposed mitigation is tracked in #55754; its scheduling and test-scope review points remain open, so a passing reproduction alone is not being treated as design approval.