openclaw - 💡(How to fix) Fix fix(slack): dual-loader module duplication causes webhook 404s [1 comments, 2 participants]

Problem

The Slack plugin's HTTP handler registry (slackHttpRoutes Map in extensions/slack/src/http/registry.ts) is module-scoped. The gateway loads this module twice through different mechanisms:

1. jiti (synchronous) — via loadBundledEntryExportSync during plugin registration (registerSlackPluginHttpRoutes → registerHttpRoute handler closure → handleSlackHttpRequest)
2. Native ESM import() — via the Bolt monitor at runtime (monitorSlackProvider → registerSlackHttpHandler)

Because jiti and native ESM maintain separate module caches, two independent slackHttpRoutes Map instances are created. The Bolt monitor registers its handlers into one Map, but when inbound webhooks arrive, the HTTP route handler reads from the other (empty) Map. Result: all Slack webhook POSTs return 404.

Impact

• All inbound Slack messages silently dropped (no error logged — the handler just returns false)
• Outbound Slack messages (agent → Slack) still work since they go through the Bolt client directly
• The [slack] http mode listening at /slack/events/... log line appears normally, masking the issue

Root Cause

The dual-loader pattern (loadBundledEntryExportSync using jiti vs native ESM import()) creates two module instances of extensions/slack/src/http/registry.ts. Any module-scoped mutable state (like the slackHttpRoutes Map) becomes silently duplicated.

This is the same class of issue documented in the codebase as "dual-loader diagnostic pattern" — the module is registered in one instance but unreachable from the other.

Suggested Fix

Back the slackHttpRoutes Map with a globalThis singleton so both module instances share the same registry:

const GLOBAL_KEY = "__openclaw_slack_http_routes__" as const;
const _global = globalThis as Record<string, unknown>;
if (!_global[GLOBAL_KEY]) {
  _global[GLOBAL_KEY] = new Map<string, SlackHttpRequestHandler>();
}
const slackHttpRoutes = _global[GLOBAL_KEY] as Map<string, SlackHttpRequestHandler>;

A more structural fix would be to ensure the registry module is only ever loaded through one mechanism (either always jiti or always native ESM), but the globalThis approach is safe and minimal.

Reproduction

1. Start the gateway
2. curl -X POST http://127.0.0.1:18790/slack/events/kaleidoscope -H "Content-Type: application/json" -d '{}'
3. Observe 404 (should be 401 from Bolt signature verification)