openclaw - 💡(How to fix) Fix [Bug]: QQ Bot streaming repeatedly falls back to static after 2026.4.29 update, likely related to dist pruning regression [2 comments, 3 participants]

[Bug]: QQ Bot streaming repeatedly falls back to static and connection timeouts after 2026.4.29 update, likely related to dist file pruning regression

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After updating to OpenClaw 2026.4.29, the QQ Bot channel exhibits severe instability: streaming responses repeatedly fall back to static mode (6+ times today), connection timeouts occur frequently, and the Gateway itself crashed once due to ERR_MODULE_NOT_FOUND. These symptoms appear consistent with the dist file pruning regression reported in #72042 (2026.4.24), and the Gateway timeout/connect issues described in #72904.

Steps to reproduce

1. Update OpenClaw to 2026.4.29 (via npm / openclaw update)
2. Use QQ Bot channel for normal C2C conversations
3. Observe that streaming responses intermittently fall back to static mode
4. Check logs for Timeout after 30000ms, connect error: gateway request timeout, and Streaming API unavailable, falling back to static

Timeline of events (2026-05-01)

Observed log patterns

Streaming fallback (6 total today):

[qqbot] [default] [qqbot:default:streaming] acquireCallbackLock: locked to "deliver"
[qqbot] [default] [qqbot:default:streaming] onDeliver: deliver in control, falling back to static
[qqbot] [default] [qqbot:default:streaming] phase: idle → aborted (source: onDeliver, reason: deliver_arrived_first_fallback_to_static)
[qqbot] [default] Streaming API unavailable, falling back to static for this deliver

Connection timeouts:

[qqbot] connect error: gateway request timeout for connect
[qqbot] [default] [qqbot:api] <<< Timeout after 30000ms
[qqbot] [default] Connection failed: Request timeout [/gateway]: exceeded 30000ms

Gateway crash (root cause):

[openclaw] Unhandled promise rejection: Error [ERR_MODULE_NOT_FOUND]: 
Cannot find module '/usr/local/lib/node_modules/openclaw/dist/restart--yFw2sFh.js' 
imported from /usr/local/lib/node_modules/openclaw/dist/run-BDvpbL6X.js

QQ session timeouts:

[qqbot] [default] Error 4009 (session timed out), will re-identify

Expected behavior

• QQ Bot streaming should remain stable throughout the day
• Gateway should not crash with ERR_MODULE_NOT_FOUND after update
• Connection timeouts should be rare, not frequent

Actual behavior

• Streaming fell back to static 6 times today (5 within 1 minute at peak)
• 85+ error/warn/timeout/fallback log entries related to QQ Bot
• Gateway crashed once due to missing dist file (restart--yFw2sFh.js)
• Multiple 30-second API timeouts
• QQ session expired and re-authenticated 3+ times

Related issues

• #72042 — [Bug]: Gateway startup fails after update to 2026.4.24 — ERR_MODULE_NOT_FOUND, 1617 dist files missing from installed package (postinstall pruning bug)
  • Our crash (restart--yFw2sFh.js missing) matches this pattern exactly
• #72904 — [Bug]: Gateway startup blocked by model pricing fetch timeout causing TUI connection failure
  • The gateway request timeout for connect pattern is similar

OpenClaw version

2026.4.29

Operating system

Ubuntu 24.04 (Linux 6.8.0-107-generic)

Node version

24.15.0

Install method

npm i -g openclaw

Channel

QQ Bot (official API, C2C)

Model

kimi-for-coding (kimi/kimi-for-coding)

Logs, screenshots, and evidence

Full journalctl output available. Key statistics:

• 146 qqbot-related log lines mentioning "streaming"
• 97 qqbot-related error/warn/timeout/fail log lines
• Gateway restarted by systemd at 12:16 (PID 1876713 replacing crashed 1814471)

Additional context

• The Gateway crash and subsequent restart appear to be the root cause of the QQ Bot instability
• After systemd auto-restarted Gateway, QQ Bot reconnected but streaming was degraded
• Session 4009 timeouts are normal QQ protocol behavior, but the frequency today was higher than usual
• Other channels (openclaw-weixin) did not exhibit the same severity of issues

Impact and severity

• Medium-High: Streaming fallback significantly degrades user experience (waiting for full response vs. real-time streaming)
• Gateway crash is critical but systemd auto-recovery masked it
• Connection timeouts may cause message loss or delayed delivery