openclaw - 💡(How to fix) Fix [Bug]: Discord outbound delivery loses adapter after plugin registry reload [3 comments, 4 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On OpenClaw 2026.5.3 with the external Discord channel plugin loaded and the Discord account connected, generic outbound delivery can lose the Discord outbound adapter, causing cron announcements and final Discord replies to fail with Unsupported channel: discord / Outbound not configured for channel: discord.

Steps to reproduce

1. Run OpenClaw 2026.5.3 as a gateway with the official external Discord plugin enabled and connected.
2. Use Discord as an inbound channel and configure at least one cron/session delivery target using delivery.mode = "announce", delivery.channel = "discord", and a Discord channel target.
3. Trigger normal gateway/plugin activity that reloads or inspects plugin/runtime state while the gateway remains running.
4. Let a Discord-targeted cron delivery run, or send a Discord message that should receive a final assistant reply.
5. Observe delivery failures even though the Discord provider remains configured/running/connected.

Expected behavior

If the Discord channel plugin is loaded and the Discord account is connected, cron announce delivery and final replies should continue resolving the Discord outbound adapter and sending messages.

Actual behavior

The gateway continues running and the Discord provider can remain connected, but generic delivery fails with errors like:

[cron:<redacted>] Unsupported channel: discord
[discord] final reply failed (target=<redacted> session=<redacted>): Error: Outbound not configured for channel: discord

A direct Discord send from the CLI still succeeds, which suggests the Discord credentials/provider are not the failing part:

openclaw message send --channel discord --target <redacted> --message <redacted> --json
# result: ok, messageId=<redacted>, channelId=<redacted>

After applying a local patch to channel plugin resolution and restarting the gateway, pending Discord deliveries were recovered successfully:

[delivery-recovery] Found 2 pending delivery entries — starting recovery
[delivery-recovery] Recovered delivery <redacted> on discord
[delivery-recovery] Recovered delivery <redacted> on discord
[delivery-recovery] Delivery recovery complete: 2 recovered, 0 failed, 0 skipped (max retries), 0 deferred (backoff)

OpenClaw version

2026.5.3 (06d46f7)

Operating system

Ubuntu 24.04 LTS, Linux x86_64

Install method

npm global, gateway launched as a systemd service

Model

openai-codex/gpt-5.5

Provider / routing chain

OpenClaw gateway -> OpenAI Codex provider

Additional provider/model setup details

No model/provider-specific behavior was observed. The failure occurs in Discord outbound delivery resolution after an agent run has already produced output.

Logs, screenshots, and evidence

Sanitized evidence from a live gateway process:

[gateway] http server listening (4 plugins: brave, browser, discord, openclaw-mem0; ...)
[discord] [default] starting provider (@OpenClaw Bot)
[discord] client initialized as <redacted>; awaiting gateway readiness

[cron:<redacted>] Unsupported channel: discord
[discord] final reply failed (target=<redacted> session=<redacted>): Error: Outbound not configured for channel: discord

Health/status at the same time showed the Discord channel configured/running/connected, with token available and no channel error. A direct openclaw message send --channel discord ... invocation from the same host/user environment succeeded.

Local code inspection of the built 2026.5.3 runtime found two relevant resolution paths:

// dist/load-ChklS5lb.js
const loadOutboundAdapterFromRegistry = createChannelRegistryLoader((entry) => entry.plugin.outbound);
async function loadChannelOutboundAdapter(id) {
  return loadOutboundAdapterFromRegistry(id);
}

// dist/channel-resolution-DICdY7UT.js
function resolveDirectFromActiveRegistry(channel) {
  const activeRegistry = getActivePluginRegistry();
  ...
}

A local hotfix changed outbound/target resolution to use/fall back through the pinned channel plugin registry / loaded channel plugin. After restart, the gateway recovered the pending Discord deliveries shown above and no new Unsupported channel: discord or Outbound not configured for channel: discord errors appeared in the observed post-fix window.

Impact and severity

Affected: Discord channel users relying on OpenClaw final replies, cron announce delivery, or pending delivery recovery.

Severity: High for Discord deployments because inbound events can be received and agent runs can complete, but the user-visible response is not delivered.

Frequency: Observed after gateway/plugin runtime activity on 2026.5.3; once in the bad state, affected Discord deliveries consistently failed until restart plus local hotfix.

Consequence: Missed Discord replies and missed cron announcements, while the gateway appears otherwise healthy.

Additional information

This looks related in theme to #54599 and older Unsupported channel delivery reports, but the observed 2026.5.3 failure is specifically Discord outbound adapter resolution in a running gateway where the external Discord plugin is loaded and direct Discord sends still work.

Temporary local workaround that restored delivery:

• Make loadChannelOutboundAdapter(id) fall back to getChannelPlugin(id)?.outbound when the channel registry lookup misses.
• Make direct outbound channel resolution read from getActivePluginChannelRegistry() instead of the mutable active plugin registry.

This report intentionally redacts channel IDs, session keys, delivery IDs, tokens, file paths, and local config details.