openclaw - ✅(Solved) Fix [Bug]: Gateway becomes unresponsive after “starting channels and sidecars...” on v2026.4.26 [1 pull requests, 3 comments, 3 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#73411Fetched 2026-04-29 06:20:17
View on GitHub
Comments
3
Participants
3
Timeline
7
Reactions
0
Author
Timeline (top)
commented ×3labeled ×2closed ×1cross-referenced ×1

On v2026.4.26, the gateway logs “http server listening” and then “starting channels and sidecars...”, but all internal HTTP routes time out and the container remains unhealthy; v2026.4.23 works in the same setup.

Observed on v2026.4.26:

  • The container stays up but remains unhealthy.
  • The gateway stages and installs bundled runtime dependencies before startup.
  • The gateway logs “http server listening” after 181.3s.
  • The last normal startup line is “starting channels and sidecars...”.
  • After that, all internal HTTP routes time out:
    • /
    • /healthz
    • /status
    • /openclaw/canvas/
  • v2026.4.23 works in the same Docker/Windows setup.

Relevant log lines:

staging bundled runtime deps before gateway startup (16 missing, 16 install specs) installed bundled runtime deps before gateway startup in 31106ms http server listening (9 plugins: acpx, active-memory, bonjour, browser, device-pair, discord, memory-core, phone-control, talk-voice; 181.3s) starting channels and sidecars... OpenRouter pricing fetch failed (timeout 60s) LiteLLM pricing fetch failed (timeout 60s)

Environment:

  • Docker Desktop on Windows / WSL2
  • Container: openclaw-openclaw-gateway-1
  • Image: openclaw:gateway-secure-patched
  • Host port: 27889 -> container 18789
  • Previous working version: v2026.4.23
  • Failing versions observed: v2026.4.24, v2026.4.25, v2026.4.26

Error Message

console.error(e);

Root Cause

On v2026.4.26, the gateway logs “http server listening” and then “starting channels and sidecars...”, but all internal HTTP routes time out and the container remains unhealthy; v2026.4.23 works in the same setup.

Observed on v2026.4.26:

  • The container stays up but remains unhealthy.
  • The gateway stages and installs bundled runtime dependencies before startup.
  • The gateway logs “http server listening” after 181.3s.
  • The last normal startup line is “starting channels and sidecars...”.
  • After that, all internal HTTP routes time out:
    • /
    • /healthz
    • /status
    • /openclaw/canvas/
  • v2026.4.23 works in the same Docker/Windows setup.

Relevant log lines:

staging bundled runtime deps before gateway startup (16 missing, 16 install specs) installed bundled runtime deps before gateway startup in 31106ms http server listening (9 plugins: acpx, active-memory, bonjour, browser, device-pair, discord, memory-core, phone-control, talk-voice; 181.3s) starting channels and sidecars... OpenRouter pricing fetch failed (timeout 60s) LiteLLM pricing fetch failed (timeout 60s)

Environment:

  • Docker Desktop on Windows / WSL2
  • Container: openclaw-openclaw-gateway-1
  • Image: openclaw:gateway-secure-patched
  • Host port: 27889 -> container 18789
  • Previous working version: v2026.4.23
  • Failing versions observed: v2026.4.24, v2026.4.25, v2026.4.26

Fix Action

Fix / Workaround

  • Docker Desktop on Windows / WSL2
  • Container: openclaw-openclaw-gateway-1
  • Image: openclaw:gateway-secure-patched
  • Host port: 27889 -> container 18789
  • Previous working version: v2026.4.23
  • Failing versions observed: v2026.4.24, v2026.4.25, v2026.4.26

Docker Desktop on Windows / WSL2. Repository updated to v2026.4.26, then gateway container rebuilt and recreated. Container: openclaw-openclaw-gateway-1 Image: openclaw:gateway-secure-patched Host port mapping: 27889 -> 18789

PR fix notes

PR #73420: fix(gateway): avoid blocking channels on model prewarm

Description (problem / solution / changelog)

Summary

  • schedule primary model prewarm in the background instead of awaiting it before channel startup
  • keep the existing bounded prewarm timeout and startup trace span
  • add coverage that model prewarm scheduling does not wait for completion

Why

On my VPS, startup tracing showed Slack was not the slow part. The gateway logged ready, then spent 134s in sidecars.channels before Slack provider startup because primary model prewarm was still ahead of startChannels().

Current main already scopes and bounds that prewarm to 5s, which is a good improvement. This PR takes the next step and makes channel startup independent from prewarm latency.

Expected behavior: chat channels can come online promptly, while model prewarm still runs as best-effort startup work.

Related work

  • #60027 adds an opt-in env escape hatch to skip startup model warmup. This PR is different: it keeps warmup enabled by default but stops it from blocking channels.
  • #71203 refreshes configured agent models.json caches during startup. That is a separate cache correctness problem and should still be reviewable on its own.
  • #73276, #73353, #73411, and #72846 describe the same broad startup stall class that recent main fixes reduced. This PR closes the remaining ordering gap where channel startup still waits for model prewarm.
  • #73298 is still open as a broader slowdown report. This PR may help if its stall includes the same prewarm-before-channel ordering.

Tests

  • pnpm exec oxfmt --check src/gateway/server-startup-post-attach.ts src/gateway/server-startup-post-attach.test.ts CHANGELOG.md
  • pnpm exec vitest run --config test/vitest/vitest.gateway.config.ts src/gateway/server-startup-post-attach.test.ts src/gateway/server-startup.test.ts
  • pnpm check:test-types

Real-world validation

Before the local production mitigation, startup trace on my OpenClaw VPS showed sidecars.channels at 134006ms and Slack socket connected around 189s after gateway ready. After skipping blocking prewarm locally, sidecars.channels dropped to 571.8ms and Slack connected about 3.8s after gateway ready.

AI-assisted: yes. I reviewed the code and tests before opening this PR.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/gateway/server-startup-post-attach.test.ts (modified, +44/-1)
  • src/gateway/server-startup-post-attach.ts (modified, +28/-7)

Code Example

Relevant v2026.4.26 log lines:

[plugins] staging bundled runtime deps before gateway startup (16 missing, 16 install specs)
[plugins] installed bundled runtime deps before gateway startup in 31106ms
[gateway] http server listening (9 plugins: acpx, active-memory, bonjour, browser, device-pair, discord, memory-core, phone-control, talk-voice; 181.3s)
[gateway] starting channels and sidecars...
[gateway/model-pricing] OpenRouter pricing fetch failed (timeout 60s)
[gateway/model-pricing] LiteLLM pricing fetch failed (timeout 60s)

Internal route test result:

=== / ===
TIMEOUT/FAILED

=== /healthz ===
TIMEOUT/FAILED

=== /status ===
TIMEOUT/FAILED

=== /__openclaw__/canvas/ ===
TIMEOUT/FAILED
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

On v2026.4.26, the gateway logs “http server listening” and then “starting channels and sidecars...”, but all internal HTTP routes time out and the container remains unhealthy; v2026.4.23 works in the same setup.

Observed on v2026.4.26:

  • The container stays up but remains unhealthy.
  • The gateway stages and installs bundled runtime dependencies before startup.
  • The gateway logs “http server listening” after 181.3s.
  • The last normal startup line is “starting channels and sidecars...”.
  • After that, all internal HTTP routes time out:
    • /
    • /healthz
    • /status
    • /openclaw/canvas/
  • v2026.4.23 works in the same Docker/Windows setup.

Relevant log lines:

staging bundled runtime deps before gateway startup (16 missing, 16 install specs) installed bundled runtime deps before gateway startup in 31106ms http server listening (9 plugins: acpx, active-memory, bonjour, browser, device-pair, discord, memory-core, phone-control, talk-voice; 181.3s) starting channels and sidecars... OpenRouter pricing fetch failed (timeout 60s) LiteLLM pricing fetch failed (timeout 60s)

Environment:

  • Docker Desktop on Windows / WSL2
  • Container: openclaw-openclaw-gateway-1
  • Image: openclaw:gateway-secure-patched
  • Host port: 27889 -> container 18789
  • Previous working version: v2026.4.23
  • Failing versions observed: v2026.4.24, v2026.4.25, v2026.4.26

Steps to reproduce

Steps to reproduce:

  1. Start from a working v2026.4.23 Docker setup on Windows / WSL2.

  2. Update the repository to v2026.4.26.

  3. Rebuild and recreate the gateway container.

  4. Start the gateway container.

  5. Wait until the logs show:

    http server listening (...) starting channels and sidecars...

  6. Check the container status:

    docker ps --filter "name=openclaw-openclaw-gateway-1"

  7. Test the internal gateway routes from inside the container:

    docker exec -it openclaw-openclaw-gateway-1 sh -lc ' for path in / /healthz /status /openclaw/canvas/; do echo "=== $path ===" timeout 6s node -e " fetch("http://127.0.0.1:18789$path\") .then(async r => { console.log(r.status, r.ok); console.log((await r.text()).slice(0,300)); }) .catch(e => { console.error(e); process.exit(1); }) " || echo "TIMEOUT/FAILED" echo done '

Expected result:

The gateway should become healthy, the dashboard should load, and /healthz and /status should respond.

Actual result:

The container remains unhealthy. The dashboard does not become usable. All tested internal routes time out after the gateway logs “starting channels and sidecars...”.

Expected behavior

The gateway should become healthy after startup. The dashboard should load normally on the mapped host port, and the internal routes /healthz and /status should respond within a few seconds.

Actual behavior

On v2026.4.26, the gateway logs “http server listening” and then “starting channels and sidecars...”. After that, the container remains unhealthy and all tested internal HTTP routes time out:

  • /
  • /healthz
  • /status
  • /openclaw/canvas/

v2026.4.23 works in the same setup.

OpenClaw version

2026.4.26

Operating system

Windows 11

Install method

Docker Desktop on Windows / WSL2. Repository updated to v2026.4.26, then gateway container rebuilt and recreated. Container: openclaw-openclaw-gateway-1 Image: openclaw:gateway-secure-patched Host port mapping: 27889 -> 18789

Model

openai/gpt-5.4-mini

Provider / routing chain

OpenAI provider via the configured OpenClaw routing chain. The gateway log shows the selected agent model as openai/gpt-5.4-mini.

Additional provider/model setup details

The issue occurs before any user model call is made. The failure appears during gateway startup, after “http server listening” and “starting channels and sidecars...”.

The gateway also logs pricing fetch timeouts for OpenRouter and LiteLLM, but those are not part of the selected agent model in this run:

  • OpenRouter pricing fetch failed (timeout 60s)
  • LiteLLM pricing fetch failed (timeout 60s)

Logs, screenshots, and evidence

Relevant v2026.4.26 log lines:

[plugins] staging bundled runtime deps before gateway startup (16 missing, 16 install specs)
[plugins] installed bundled runtime deps before gateway startup in 31106ms
[gateway] http server listening (9 plugins: acpx, active-memory, bonjour, browser, device-pair, discord, memory-core, phone-control, talk-voice; 181.3s)
[gateway] starting channels and sidecars...
[gateway/model-pricing] OpenRouter pricing fetch failed (timeout 60s)
[gateway/model-pricing] LiteLLM pricing fetch failed (timeout 60s)

Internal route test result:

=== / ===
TIMEOUT/FAILED

=== /healthz ===
TIMEOUT/FAILED

=== /status ===
TIMEOUT/FAILED

=== /__openclaw__/canvas/ ===
TIMEOUT/FAILED

Impact and severity

High. The gateway container stays up but remains unhealthy, and the dashboard is not usable. This blocks normal use of OpenClaw on v2026.4.26. I had to roll back to v2026.4.23.

Additional information

Failing versions observed in this setup: v2026.4.24, v2026.4.25, v2026.4.26. Previous working version: v2026.4.23.

extent analysis

TL;DR

The issue can likely be resolved by investigating and addressing the timeouts occurring during the startup of the OpenClaw gateway, specifically after the "starting channels and sidecars..." log line.

Guidance

  1. Investigate the "starting channels and sidecars..." process: This step seems to be where the issue arises, as all internal HTTP routes time out after this log line. Understanding what this process entails and why it might be causing timeouts is crucial.
  2. Check for dependency or configuration issues: Given that the gateway stages and installs bundled runtime dependencies before startup, there might be a version conflict or a missing dependency causing the issue.
  3. Review the pricing fetch timeouts: Although the models (OpenRouter and LiteLLM) are not part of the selected agent model, their pricing fetch failures could indicate a broader connectivity or configuration problem affecting the gateway's ability to start up properly.
  4. Compare configurations between v2026.4.23 and v2026.4.26: Since v2026.4.23 works but v2026.4.26 does not, comparing the configurations, dependencies, and startup processes between these two versions might highlight the root cause.

Example

No specific code example can be provided without more details on the startup process or the dependencies involved. However, reviewing the log lines and the steps to reproduce should help in identifying where the issue lies.

Notes

The provided information suggests a regression issue introduced between versions v2026.4.23 and v2026.4.26. The exact cause is not clear without further investigation into the startup process and dependency management of the OpenClaw gateway.

Recommendation

Apply a workaround by rolling back to v2026.4.23 until the root cause of the timeouts in v2026.4.26 can be identified and addressed. This ensures the gateway remains operational while the issue is investigated further.

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

The gateway should become healthy after startup. The dashboard should load normally on the mapped host port, and the internal routes /healthz and /status should respond within a few seconds.

Still need to ship something?

×6

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

Back to top recommendations

TRENDING