PR #62363: fix(routing): isRoutableChannel accepts npm-installed plugin channels (feishu webchat regression)

• Repository: openclaw/openclaw
• Author: hclsys
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/62363

Description (problem / solution / changelog)

Root cause

isRoutableChannel() in src/auto-reply/reply/route-reply.ts gated cross-channel reply routing with:

return normalizeChatChannelId(channel) !== null || normalizeChannelId(channel) !== null;

When a channel plugin is installed via npm (e.g. @openclaw/feishu) rather than being bundled in the host package:

• normalizeChatChannelId(channel) → null (channel not in the static bundled catalog CHAT_CHANNEL_ID_SET)
• normalizeChannelId(channel) (= normalizeAnyChannelId) → null if the runtime plugin registry has not yet been populated at the time this check runs

Both returning null made isRoutableChannel("feishu") === false. In the ACP/webchat path where Provider = "webchat", Surface = "feishu", OriginatingChannel = "feishu", shouldRouteToOriginating therefore evaluated to false, and the reply was delivered to the webchat dispatcher instead of being routed back to Feishu.

Call path (src/auto-reply/reply/routing-policy.ts):

resolveReplyRoutingDecision()
  shouldRouteToOriginating = !suppressDirectUserDelivery
                           && !isInternalWebchatTurn
                           && params.isRoutableChannel(originatingChannel)   ← returns false
                           && params.originatingTo
                           && originatingChannel !== currentSurface
  // → false → no routeReply → sendFinalReply on webchat dispatcher

Runtime path reaches the bug (G9): any Feishu message arriving via ACP/webchat bridge sets Provider = "webchat", Surface = "feishu", OriginatingChannel = "feishu". The fix is exercised on every such turn.

Fix

Add a final fallback to normalizeMessageChannel() which returns any non-empty, non-webchat string as-is. This ensures any well-formed channel id is treated as routable regardless of bundle/registry population status:

// src/auto-reply/reply/route-reply.ts  line ~244
const normalized = normalizeMessageChannel(channel);
return normalized != null && normalized !== INTERNAL_MESSAGE_CHANNEL;

The two-level fast-path (bundled catalog → runtime registry) is preserved; the fallback only fires when both miss.

Cross-channel impact (G8)

The same guard affects every npm-installed plugin channel. LINE, Zalo, and any custom channel installed as @openclaw/<channel> that is not bundled would have the same routing failure. The fix covers all of them.

Tests

New describe("isRoutableChannel") block in route-reply.test.ts:

• returns false for undefined
• returns false for webchat (internal channel)
• returns true for a channel registered in the runtime plugin registry
• returns true for feishu even when not present in runtime registry (npm-installed plugin regression) ← regression test for this issue
• returns true for other npm-installed plugin channels not in bundled catalog (LINE, Zalo)

The existing test at line 844 in dispatch-from-config.test.ts mocked isRoutableChannel to hardcode "feishu" as routable — masking the production bug. That test now validates the integrated path rather than relying on the mock bypass.

Closes #62304

Changed files

• src/auto-reply/reply/route-reply.test.ts (modified, +52/-1)
• src/auto-reply/reply/route-reply.ts (modified, +15/-1)