Symptom
OpenClaw's checkForUpdate() (called once on gateway start, plus from a couple of registered commands) frequently fails on cold start with:
[plugins] Auto-update check failed: The operation was aborted due to timeout
The expected ⬆️ Hivemind update available: X.Y.Z → ... Run: hivemind update notice never renders.
Reproduces on every fresh systemctl --user restart openclaw-gateway against a cold gateway. Confirmed on the run from 2026-05-07 at 07:32:32 (PR #97 follow-ups) and again at 07:42:13 (PR #98 follow-ups).
Where
Three call sites in openclaw/src/index.ts, all using AbortSignal.timeout(3000):
openclaw/src/index.ts:194 — initial checkForUpdate on gateway startopenclaw/src/index.ts:667 — registered command pathopenclaw/src/index.ts:949 — second registered command path
(The original PR #97 followup documented this as a 5s timeout; main is now at 3s, which is even more likely to trip on a cold gateway.)
Confirmation that the registry itself is fast
$ time curl -sS -o /dev/null https://registry.npmjs.org/@deeplake/hivemind/latest
real 0m0.167s
Registry steady-state response is ~167ms. The 3s budget is exceeded by cold TLS + bonjour-watchdog noise running concurrently with plugin register, not by the network call itself.
Suggested fix
Either:
- Bump
AbortSignal.timeout(3000) to AbortSignal.timeout(10000) at all three sites (matches what's plenty in CI/dev observed steady state — 167ms × 60x headroom).
- Or: keep 3000 and add a single
AbortError retry with ~1s backoff (more invasive but eliminates the cold-start race entirely).
Lean toward the timeout bump — minimal diff, no new failure modes.
What this followup carried over from
.followups-pr97.md § "OpenClaw — version-check timed out at 5s during test run". The fix was deferred at the time so PR #97 could land.
Symptom
OpenClaw's
checkForUpdate()(called once on gateway start, plus from a couple of registered commands) frequently fails on cold start with:The expected
⬆️ Hivemind update available: X.Y.Z → ... Run: hivemind updatenotice never renders.Reproduces on every fresh
systemctl --user restart openclaw-gatewayagainst a cold gateway. Confirmed on the run from 2026-05-07 at 07:32:32 (PR #97 follow-ups) and again at 07:42:13 (PR #98 follow-ups).Where
Three call sites in
openclaw/src/index.ts, all usingAbortSignal.timeout(3000):openclaw/src/index.ts:194— initialcheckForUpdateon gateway startopenclaw/src/index.ts:667— registered command pathopenclaw/src/index.ts:949— second registered command path(The original PR #97 followup documented this as a 5s timeout; main is now at 3s, which is even more likely to trip on a cold gateway.)
Confirmation that the registry itself is fast
Registry steady-state response is ~167ms. The 3s budget is exceeded by cold TLS + bonjour-watchdog noise running concurrently with plugin register, not by the network call itself.
Suggested fix
Either:
AbortSignal.timeout(3000)toAbortSignal.timeout(10000)at all three sites (matches what's plenty in CI/dev observed steady state — 167ms × 60x headroom).AbortErrorretry with ~1s backoff (more invasive but eliminates the cold-start race entirely).Lean toward the timeout bump — minimal diff, no new failure modes.
What this followup carried over from
.followups-pr97.md§ "OpenClaw — version-check timed out at 5s during test run". The fix was deferred at the time so PR #97 could land.