stoic dirge
The reproducible symptom is a long Node event-loop lag inside the OpenClaw gateway/OcuClaw relay process during an embedded send-message run. Latest profiled run
caught a 37.581s relay event-loop lag sample at 2026-04-29T01:56:36.594Z. The operation itself acked upstream in 67ms, then final OpenClaw completion arrived at
61.121s. The connected app stayed healthy: outbox depths were 0, pipeline queue 0, and there was no app-side write timeout/backpressure.
CPU profile for the estimated blocked window points strongly at OpenClaw plugin/tool registry work, not OcuClaw app code. Inclusive samples were roughly:
runEmbeddedAttempt 90.83%, createOpenClawTools 90.78%, loadOpenClawPlugins 79.15%, resolveRuntimePluginRegistry 76.05%, resolvePluginCapabilityProviders 74.91%,
withBundledRuntimeDepsFilesystemLock 47.30%, mirrorBundledPluginRuntimeRoot 44.39%, mirrorBundledRuntimeDistRootEntries 40.66%. Self-heavy frames included
path.resolve, readFileSync/readFileUtf8, lstat, existsSync, realpath, and the regex for //#region extensions/....
One concrete source finding: in installed openclaw@2026.4.26, shouldMaterializeBundledRuntimeMirrorDistFile(sourcePath) appears to synchronously read
each .js/.cjs/.mjs dist file and test BUNDLED_RUNTIME_MIRROR_PLUGIN_REGION_RE; I did not see a persistent materialization decision cache there. Also, the hot
inclusive path includes image/video/music provider tool construction, especially createVideoGenerateTool, createImageGenerateTool, createMusicGenerateTool, and
listVideoGenerationProviders. This makes me suspect repeated broad capability-provider resolution for bundled providers is triggering full registry loads and
bundled runtime mirror scans on the hot embedded-run path.
lyric lichen