openclaw - 💡(How to fix) Fix [Bug]: Gateway boot still blocks ~75s on pricing fetch despite fix 7d9dc8cf24 (macOS, 2026.4.26 be8c246, Node 25.9.0) [1 comments, 2 participants]

Bug type

Regression after partial fix

Summary

Gateway boot blocks ~75 seconds waiting for OpenRouter pricing fetch and LiteLLM pricing fetch to time out at 60s, despite running on a build that contains the fix from #72971 (commit 7d9dc8cf24, "reuse plugin manifests for model pricing refresh"). Standalone fetch to the same URLs succeeds in 89–148ms from the same host.

Filing per @steipete's request in #72971: "Please reopen or file a fresh issue if this still reproduces on a build containing 7d9dc8cf24 or newer." Cross-referencing open tracker #73323 (Windows reproduction).

Steps to reproduce

1. Install [email protected] (be8c246) (348 commits ahead of fix 7d9dc8cf24).
2. launchctl bootout + launchctl bootstrap the gateway LaunchAgent (or openclaw daemon restart).
3. Tail /tmp/openclaw/openclaw-YYYY-MM-DD.log while polling openclaw health until 200.
4. Boot consistently takes ~100s end-to-end; gateway emits gateway ready ~80s after http server listening.

Expected

With fix 7d9dc8cf24 in place, pricing fetch failures should not block boot. gateway ready should fire shortly after channel/sidecar startup regardless of pricing endpoint reachability.

Actual

Boot timeline (single restart):

01:58:31.216  http server listening (18 plugins)
01:58:31.688  serve enabled: https://mac-mini...
              ⟵ 75 seconds of complete log silence ⟶
01:59:47.238  [default] starting provider (BlueBubbles)
01:59:47.796  OpenRouter pricing fetch failed (timeout 60s): TimeoutError
01:59:52.225  [voice-call] Webhook server listening
01:59:52.476  gateway ready

End-to-end: daemon restart cmd returned at +20s, gateway healthy at +101.6s.

Stable across 5 consecutive boots in the current log:

$ grep -c "OpenRouter pricing fetch failed" /tmp/openclaw/openclaw-2026-04-29.log
5

All 5 boots: OpenRouter timeout at 60s, immediately followed by LiteLLM timeout at 60s.

Network is fine — fetches fast outside the gateway:

FETCH_TIMEOUT_MS = 6e4 confirmed in dist/usage-format-CxRWdJfK.js.

OpenClaw version

2026.4.26 (be8c246), commit dated 2026-04-28T01:12:58Z. Verified to be 348 commits ahead of fix 7d9dc8cf24 (2026-04-27T09:25:41Z) via gh api repos/openclaw/openclaw/compare/7d9dc8cf24...be8c246 → {ahead: 348, behind: 0}.

Operating system

macOS (Darwin 25.5.0)

Install method

pnpm global (~/Library/pnpm/global/5/node_modules/openclaw); Node v25.9.0; LaunchAgent (ai.openclaw.gateway.plist)

Provider / routing chain

Gateway-internal hardcoded fetches:

• https://openrouter.ai/api/v1/models
• https://raw.githubusercontent.com/BerriAI/litellm/main/model_prices_and_context_window.json

Hypothesis

Fix 7d9dc8cf24 removed the plugin-manifest-rebuild coupling, but the pricing fetch itself is still on the boot critical path on macOS. The 75-second silent gap aligns exactly with the 60s FETCH_TIMEOUT_MS plus a few seconds of slack — channel/sidecar startup (BlueBubbles, voice-call, Telegram) does not run until the fetch promise rejects.

A config/env opt-out (tracked in #73124) would unblock affected users while the underlying network mismatch is investigated. Cache-only mode (use ~/.openclaw/cache/openrouter-models.json if present, skip fetch) would be a minimal-risk workaround.

Workaround in use

None confirmed. OPENROUTER_MODELS_URL env var is read by the catalog code path but it is unclear whether it short-circuits the pricing-fetch path specifically.