Skip to content

[Bug]: Discord final replies can still lose outbound adapter on 2026.6.1 #90162

@hoyanhan

Description

@hoyanhan

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On stable 2026.6.1 (2e08f0f), Discord inbound handling and the agent turn completed, but final reply delivery failed with:

Error: Outbound not configured for channel: discord

The gateway was otherwise healthy, Discord status was OK, config validation passed, and @openclaw/discord@2026.6.1 was loaded. After a gateway restart, delivery recovery replayed the single pending Discord reply successfully.

This looks related to closed issues #77254, #84147, and especially #84568. I am filing a new issue because those reports are closed as fixed, while the current stable 2026.6.1 install and current main source still show the same risky active-registry fallback path in src/channels/plugins/registry-loader.ts.

Steps to reproduce

  1. Run OpenClaw 2026.6.1 with the official Discord plugin enabled and connected.
  2. Use Discord as an inbound channel and send a normal message that should produce a final assistant reply.
  3. Observe that the agent turn completes, but the final Discord reply is not posted.
  4. Check gateway logs for Outbound not configured for channel: discord.
  5. Restart the gateway and observe delivery recovery replay the pending Discord delivery.

Expected behavior

If Discord inbound is connected and the Discord plugin is loaded, final assistant replies should continue resolving the Discord outbound adapter and post to the originating Discord channel without requiring a gateway restart.

Actual behavior

The agent run completed, but final reply delivery failed:

[plugins] openclaw-mem0: skills-mode agent_end (no auto-capture)
[discord] final reply failed (target=<redacted> session=<redacted>): Error: Outbound not configured for channel: discord

After a gateway restart, the pending delivery recovered:

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

OpenClaw version

2026.6.1 (2e08f0f)

Operating system

Ubuntu 24.04 LTS, Linux x86_64

Install method

npm global, gateway launched as a systemd service

Model

gpt-5.5

Provider / routing chain

OpenClaw gateway -> OpenAI Codex runtime

Additional provider/model setup details

The model/provider path appears healthy. The failure happened after an agent turn had already produced output, and the failed surface was Discord final-reply delivery.

openclaw status --deep after restart showed Discord OK and the active session runtime as OpenAI Codex.

The Discord plugin was loaded as @openclaw/discord@2026.6.1 from the npm-project install. plugins inspect discord also reported a duplicate plugin-id warning from an older install/copy, but the active selected runtime was the npm-project Discord plugin.

Logs, screenshots, and evidence

Sanitized live checks:

openclaw --version
OpenClaw 2026.6.1 (2e08f0f)

curl /health
{"ok":true,"status":"live"}

openclaw config validate
Config valid: ~/.openclaw/openclaw.json

Current source inspection on main shows src/channels/plugins/registry-loader.ts still falls back from the channel registry to getActivePluginRegistry() after a channel-registry miss. That matches the root-cause family described in #84568.

Current src/infra/outbound/deliver.ts calls loadBootstrappedOutboundAdapter(), then resolveOutboundChannelMessageAdapter(), and throws Outbound not configured for channel: ${params.channel} when neither path yields a send-capable handler.

Current src/infra/outbound/channel-bootstrap.runtime.ts records a per-channel/per-registry bootstrap attempt before verifying that the resulting registry has a send-capable channel entry. Inference: if bootstrap resolves without making Discord send-capable, later retries can be skipped for the same registry version until process restart clears the attempt state.

Impact and severity

Affected: Discord users relying on final assistant replies.

Severity: High for Discord deployments because inbound messages can be processed and agent turns can complete, but the user-visible final response is not delivered until restart recovery.

Frequency: Observed once on stable 2026.6.1; the source path matches previously reported closed regressions.

Additional information

Related closed issues: #77254, #84147, #84568.

This report intentionally redacts Discord channel IDs, session keys, delivery IDs, message content, tokens, hostnames, IPs, file paths containing usernames, and local config details.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High-priority user-facing bug, regression, or broken workflow.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.clawsweeper:queueable-fixClawSweeper marked this issue as an existing queue_fix_pr work candidate.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions