openclaw - 💡(How to fix) Fix [Bug]: channels.discord.commands.native=false still fetches slash commands on startup (GET /applications/.../commands times out) [1 comments, 2 participants]

Summary

Setting channels.discord.commands.native: false is supposed to disable native slash command deployment, but on startup the gateway still issues a GET /applications/{appId}/commands request. On a slow or congested network this request takes 30–40 seconds and blocks the Node.js event loop before it finally aborts with a fetch-timeout.

Observed behaviour

Gateway log on a clean startup with channels.discord.commands.native: false and channels.discord.applicationId pre-configured:

[discord] [default] starting provider
[fetch-timeout] fetch timeout reached; aborting operation   ← ~38s later
[discord] channels resolved: …
[discord] cleared native commands (commands.native=false)
[discord] logged in to discord as … (Lobster)

The [fetch-timeout] at startup is the GET /applications/{appId}/commands call. It blocks for ~38 seconds before being aborted, and then cleared native commands runs a DELETE call immediately after.

The liveness warning fired at startup shows:

eventLoopDelayMaxMs=25534.9 eventLoopUtilization=1 cpuCoreRatio=1.01

This 25-second delay is caused directly by the blocked GET call.

Expected behaviour

When commands.native: false is set, no Discord slash-command API calls should be made at all (neither GET /applications/.../commands nor DELETE). The gateway should skip the entire slash-command lifecycle and proceed to logged in immediately.

Steps to reproduce

1. Set channels.discord.commands.native: false in openclaw config
2. Set channels.discord.applicationId: "<your app id>" (to skip the startup REST lookup)
3. Restart the gateway
4. Observe [fetch-timeout] appearing ~38 seconds after [discord] starting provider, followed by cleared native commands

Environment

• openclaw version: 2026.4.29
• Host: Intel Celeron N4000, 2 cores, Ubuntu 24.04 (low-power embedded board)
• Discord provider with a single guild

Related

Related to #76188 (chain of CPU saturation issues on low-power hosts). This GET-then-DELETE is one of the remaining startup-time event-loop blockers after the slash command PATCH rate-limit issue was addressed.