openclaw - 💡(How to fix) Fix Gateway crash: SyntaxError on bundled `provider-discovery.runtime.js` export `n` after in-place upgrade (2026.5.28)

Summary

Gateway crashed with an unhandled SyntaxError claiming ./provider-discovery.runtime.js does not export n, even though the export is present in the bundled file. Appears to be an ESM module-cache / hot-reload race after an in-place dist update (npm/pnpm upgrade replacing files under a running process).

Version / environment

• OpenClaw: 2026.5.28 (/opt/homebrew/lib/node_modules/openclaw, pnpm install path)
• Node: v25.6.0
• OS: macOS 15.6 (arm64)
• Install: LaunchAgent openclaw.gateway (auto-restarted by launchd)

Error

From ~/.openclaw/logs/gateway.err.log at 2026-05-31T18:31:59-07:00:

[openclaw] Unhandled promise rejection: file:///opt/homebrew/lib/node_modules/openclaw/dist/provider-runtime-Cp-fJ4cK.js:13
import { n as resolvePluginDiscoveryProvidersRuntime } from "./provider-discovery.runtime.js";
         ^
SyntaxError: The requested module './provider-discovery.runtime.js' does not provide an export named 'n'
    at ModuleJob.#asyncInstantiate (node:internal/modules/esm/module_job:319:21)
    at processTicksAndRejections (node:internal/process/task_queues:104:5)
    at ModuleJob.run (node:internal/modules/esm/module_job:422:5)
    at onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:655:26)

Stability bundle written: ~/.openclaw/logs/stability/openclaw-stability-2026-06-01T01-31-59-310Z-62747-unhandled_rejection.json.

Why this is weird

The dist file does export n. Last line of dist/provider-discovery.runtime-D6oiOra8.js:

export { resolvePluginDiscoveryProvidersRuntime as n, clearProviderDiscoveryModuleLoaders as t };

And dist/provider-discovery.runtime.js is just a barrel re-export:

export * from "./provider-discovery.runtime-D6oiOra8.js";

So statically the import in provider-runtime-Cp-fJ4cK.js line 13 should resolve fine. The fact that Node's ESM linker disagrees at runtime suggests either:

1. Race during in-place upgrade: dist files were rewritten under the running process and Node cached a stale module record for provider-discovery.runtime.js before the barrel re-export was finalized.
2. Hot-reload module-cache invalidation bug: clearNativeRequireJavaScriptModuleCache / getCachedPluginModuleLoader (referenced in provider-discovery.runtime-D6oiOra8.js) cleared a require() cache entry but not a corresponding ESM module record, leaving an inconsistent view.
3. TOCTOU on the barrel file: provider-discovery.runtime.js was read while it still contained an older export * target that didn't have the renamed n symbol.

All dist files have mtime May 31 17:01 and the crash was at 18:31 — ~90 minutes after the update, but the process had been running across the upgrade.

Knock-on effects

The crash itself isn't catastrophic, but the next gateway startup (auto-relaunch by launchd at 2026-06-01T01:32:11Z) failed with:

Invalid config at /Users/.../openclaw.json. bindings.2.agentId: Unknown agent id "ruby" (not in agents.list). Run "openclaw doctor --fix" to repair, then retry.

That's a separate validation tightening in 2026.5.28 (good!), but the config auto-migration written at the time of the crash kept a binding for an agent id (ruby) whose agentDir entry under agents.subagents had already been dropped by a prior migration. So 2026.5.28 left the config in a self-inconsistent state on startup. openclaw doctor --fix cleaned it.

Suggestion: when migrating agents.subagents, the same pass should drop any bindings[].agentId (and channel accounts[].agentId) that no longer resolve.

Repro signal

Hard to repro deterministically (it's a race), but a probable trigger is:

1. Run gateway under launchd (long-lived).
2. pnpm i -g openclaw@latest (or whatever the auto-updater path is) while it's running, replacing files under dist/ in place.
3. Wait for any code path that re-imports provider-discovery.runtime.js via the plugin loader cache.

Attachments

Happy to upload the full stability bundle (~220 KB JSON) if useful — it's redacted of host name but contains capability/loader snapshot. Reply and I'll attach.

Workaround

openclaw doctor --fix followed by gateway restart. Already back to healthy on this host.