openclaw - 💡(How to fix) Fix Discord native slash commands can time out when duplicate accounts share a bot token and one has native commands disabled [1 comments, 2 participants]

Summary

In a live OpenClaw install, native Discord /side and /steer routed to the correct Jarvis application after command registry cleanup, but Discord showed The application did not respond for both commands.

This looked like a missing/deferred ACK problem at first, but local diagnosis found a duplicate-account runtime hazard:

• channels.discord.accounts.main and channels.discord.accounts.default used the same Jarvis bot token / application id.
• main had native commands enabled and owned /side + /steer.
• default was also enabled, but had commands.native=false and commands.nativeSkills=false.
• The Discord API registry was correct: Jarvis app had /side and /steer; specialist apps had 0 commands.
• Yet native interactions timed out under Jarvis APP because the live gateway had a second runtime client for the same Jarvis app whose command table did not include the native commands.

Local mitigation was to disable the duplicate default Discord account and restart the gateway so only main runs the Jarvis bot token.

Evidence

Before mitigation:

• Native /steer: Discord UI showed Ramit used /steer, response from Jarvis APP, then The application did not respond.
• Native /side: Discord UI showed Ramit used /side, response from Jarvis APP, then The application did not respond.
• main and default had the same application id (1497344959878139914) from /oauth2/applications/@me.
• default was enabled while commands.native=false.

After mitigation:

• Config change: channels.discord.accounts.default.enabled=false.
• Gateway restarted.
• openclaw channels status --deep --json reports:
  • main: enabled=true, running=true, connected=true, application id 1497344959878139914, bot Jarvis.
  • default: enabled=false, running=false, lastError=disabled.
  • specialist accounts remain enabled under separate app ids.
• Discord registry check still shows specialists have globalCount=0, guildCount=0, no /side, no /steer; Jarvis/main has /side and /steer.

Expected Behavior

OpenClaw should not allow a duplicate enabled Discord account with the same bot token/application id to create a second live client with a different native command table. At minimum it should warn loudly and avoid starting the duplicate runtime client.

Native interactions should always ACK/defer or produce an explicit error. A no-op command miss in the runtime dispatcher should not leave Discord to render The application did not respond.

Suggested Fixes

• Detect duplicate enabled Discord accounts that resolve to the same application id/token and fail configuration validation or doctor with an actionable warning.
• During provider startup, skip duplicate live clients for the same Discord application id unless explicitly supported.
• In the interaction dispatcher, if an application command is received but no runtime command handler is registered, log the command/app/account context and respond with a clear ephemeral error if possible.
• Keep per-account native command disable support, but prevent it from producing an enabled duplicate client for an app that still has registered commands through another account.