Slow Discord Gateway Startup After 4.1 → 4.20 Upgrade

Summary

Following the closure of #69841 (umbrella issue), this is a focused report on the remaining Discord gateway startup delay. After upgrading from 4.1 to 4.20, the OpenClaw gateway takes an unusually long time to start, and even after the gateway process is running, Discord connection takes an additional 1–2 minutes before the bot becomes responsive in channels.

This issue persists after bundled plugin runtime dependencies are confirmed staged (see #69923 for the deps-staging class).

Environment

Problem Description

1. Slow Gateway Startup

Running openclaw gateway start (or restart) takes significantly longer than on 4.1. The terminal shows no output for a noticeable period, then plugin-loading messages appear slowly.

2. Discord Connection Delay

Even after the gateway process reports as running:

• The Discord bot does not immediately appear online
• 1–2 minutes elapse before it responds to messages or slash commands
• During this window, @Bütyök mentions or /status slash commands time out or receive no response

3. doctor --non-interactive Hangs

Running OPENCLAW_PLUGIN_LOAD_PROFILE=1 openclaw doctor --non-interactive appears to hang indefinitely (tested 2026-04-22, killed after 60s+). This suggests the plugin/runtime staging check itself is a bottleneck.

Steps to Reproduce

1. Start from a working 4.1 install on Ubuntu EC2
2. Upgrade to 4.20 (openclaw update or manual install)
3. Run openclaw gateway start
4. Observe startup duration vs. 4.1 baseline
5. In Discord, try @bot mention or /status immediately after gateway reports running
6. Observe 1–2 minute delay before bot responds

Expected Behavior

• Gateway startup should complete within seconds (as it did on 4.1)
• Discord bot should be responsive immediately after gateway reports ready
• doctor should complete quickly even with OPENCLAW_PLUGIN_LOAD_PROFILE=1

Related Issues

• #69841 – Original umbrella issue (partially fixed, closed as split)
• #69869 – Fixed the Discord /status ephemeral follow-up leak
• #69923 – Bundled runtime dependency staging (acknowledged by maintainer as the right home for startup repair work)

Notes

• Bundled plugin runtime deps are installed globally and accessible (confirmed via npm list -g in #69841)
• The delay appears to be after deps are staged, not during install
• No high CPU or memory pressure observed during startup (t1.small EC2, typical load)
• openclaw doctor without --non-interactive also reports missing bundled deps falsely

Request

Please advise on how to capture more detailed startup profiling data. The OPENCLAW_PLUGIN_LOAD_PROFILE=1 env var does not seem to produce visible output in our environment—possibly because the process hangs before reaching the profiling phase.

/cc @steipete