Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: sidecars.channels blocks gateway ready for ~45s on v2026.4.27 (Linux, minimal channel config) [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#75051•Fetched 2026-05-01 05:38:42
View on GitHub
Comments
2
Participants
2
Timeline
5
Reactions
2
Author
Quantum505VoidQuantum505Void
Participants
clawsweeper[bot]clawsweeper[bot]Quantum505VoidQuantum505Void
Timeline (top)
commented ×2closed ×1mentioned ×1subscribed ×1

Root Cause

  • #65444 (feat: lazy-load channel plugins) — directly addresses this
  • #62364 (slow startup / models.list) — different root cause but same symptom class

Code Example

startup trace: sidecars.channels       45277.9ms   total=50287.2ms
startup trace: sidecars.plugin-services  361.2ms   total=50650.3ms
startup trace: sidecars.memory             0.1ms
startup trace: sidecars.total          46712.7ms   total=50667.2ms
startup trace: sidecars.ready             0.9ms
startup trace: runtime.post-attach     46867.4ms   total=50670.8ms
RAW_BUFFERClick to expand / collapse

Environment

  • OpenClaw version: 2026.4.27 (cbc2ba0)
  • OS: Ubuntu 24.04 (x86_64), Linux 6.17.0-22-generic
  • Node: v24.15.0
  • Channel plugins: only webchat actively used; previously disabled 44 unused provider plugins

Problem

Gateway startup is still blocked for ~45 seconds by sidecars.channels on v2026.4.27. This has not improved compared to prior versions.

Startup trace from today's log (2026-04-30T18:50):

startup trace: sidecars.channels       45277.9ms   total=50287.2ms
startup trace: sidecars.plugin-services  361.2ms   total=50650.3ms
startup trace: sidecars.memory             0.1ms
startup trace: sidecars.total          46712.7ms   total=50667.2ms
startup trace: sidecars.ready             0.9ms
startup trace: runtime.post-attach     46867.4ms   total=50670.8ms

Total time to gateway ready: ~50 seconds.

Timeline

Versionsidecars.channelsTotal
2026.4.21 (before provider cleanup)~34s~40s
2026.4.21 (after disabling 44 unused providers)~34s~40s
2026.4.27~45s~50s

Disabling 44 unused provider plugins had no effect on sidecars.channels time. The bottleneck is purely in channel sidecar initialization, not providers.

Additional observations

  • Side effect during startup: bonjour advertiser gets stuck in announcing state for 34s, triggering a restart warning — suggesting the event loop is significantly blocked during channel init.
  • The gateway HTTP port responds within ~1.4s, but the gateway ready event is not emitted until all sidecars finish, so the TUI/clients appear frozen for the full 50s.

Expected behavior

sidecars.channels should either:

  1. Initialize lazily (connect on first message, not at boot) — already proposed in #65444
  2. Initialize in parallel without blocking gateway ready
  3. At minimum, emit gateway ready once core is loaded; channel readiness can be async

Related

  • #65444 (feat: lazy-load channel plugins) — directly addresses this
  • #62364 (slow startup / models.list) — different root cause but same symptom class

extent analysis

TL;DR

The most likely fix for the slow gateway startup is to implement lazy loading of channel plugins, as proposed in #65444, to prevent blocking the gateway ready event.

Guidance

  • Investigate the feasibility of implementing lazy loading of channel plugins, as described in #65444, to improve startup time.
  • Review the sidecars.channels initialization code to identify potential bottlenecks and areas for parallelization.
  • Consider emitting the gateway ready event once the core is loaded, allowing channel readiness to be handled asynchronously.
  • Analyze the bonjour advertiser's behavior and its impact on the event loop during startup.

Example

No code snippet is provided, as the issue does not contain sufficient technical details to create a specific example.

Notes

The provided timeline and observations suggest that the bottleneck is in the sidecars.channels initialization, and disabling unused provider plugins had no effect. The proposed lazy loading of channel plugins in #65444 may address this issue.

Recommendation

Apply the workaround proposed in #65444, implementing lazy loading of channel plugins, as it directly addresses the slow startup issue and has the potential to significantly improve the gateway's startup time.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

sidecars.channels should either:

  1. Initialize lazily (connect on first message, not at boot) — already proposed in #65444
  2. Initialize in parallel without blocking gateway ready
  3. At minimum, emit gateway ready once core is loaded; channel readiness can be async
#generation error#database connection#vector store#embedding generation#cache error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING