OpenClaw Main Moves Gateway Warmups Off Latency-Critical RPC Paths

OpenClaw has merged a follow-up startup-availability correction: rather than merely delaying memory-core initialization after readiness, PR #119710 removes the unsolicited startup warmup so memory managers initialize only on demand.

Two newer fixes apply the same ownership rule elsewhere. PR #119742 keeps chat.startup from initiating full model-catalog discovery for large multi-agent rosters, and PR #118848 replaces per-card child-table queries that could let a large Workboard monopolize the Gateway event loop.

These are main-branch changes. No source reviewed here establishes the first package containing the full set.

Readiness must mean the control plane can answer

PR #119676 first deferred memory-manager initialization for five seconds and fenced that work to the active Gateway generation. PR #119710 supersedes the operational strategy by removing the startup warmup hook entirely after post-ready health, first-device and config.get calls could still stall when the timer fired.

On-demand initialization can make the first real memory operation colder. It also gives that operation an explicit owner instead of charging unrelated control-plane requests for speculative work.

This was not one isolated warmup

The earlier merges addressed the same operational pattern at different owners:

• PR #119607 makes context prewarm cooperative so unrelated RPCs and timers can run.
• PR #119562 reuses the already-published context-prewarm owner instead of creating work from the health path.
• PR #119377 removes speculative post-ready session-catalog prewarming after exact-environment evidence found provider-owned discovery blocking unrelated RPCs for tens of seconds.
• PR #119369 prevents chat.metadata preparation from blocking concurrent Gateway RPCs.

The source record for #119377 reports an affected-host red run where a session-catalog phase occupied the Gateway for 114.7 seconds before context prewarm began, while unrelated requests waited 16–70 seconds. Those are upstream incident observations, not general performance promises.

Interpretation: startup work is being split into three classes: process-stable work worth publishing once, request-owned work that should run only when asked, and optional warmup that must yield and obey lifecycle cancellation. Mixing those classes is what makes a “ready” Gateway look hung.

Chat startup and Workboard reads had the same blast radius

PR #119742 closes a remaining request-time branch in chat.startup. On the affected large-roster instance, repeated calls took 252–339 seconds at roughly one CPU core while model-catalog and per-agent projection work starved unrelated RPCs and channels. Startup now consumes lifecycle-prepared projections instead of initiating discovery on that request path.

PR #118848 fixes a different trigger with the same event-loop consequence. The Workboard SQLite card store queried child tables separately for each card; a large board could block the Gateway for more than two minutes, restart channel polling and time out requests. The landed path loads each child table once for the board and groups rows by card ID.

Those timings are upstream observations from affected environments, not performance guarantees. The operator lesson is broader: database access can be asynchronous and still monopolize service if request count grows quadratically or serially with the result set.

Who should prioritise a containing build

Prioritise this line of fixes when:

• orchestration probes health or configuration immediately after readiness;
• the default memory plugin is enabled;
• several agents or provider session catalogues are configured;
• providers scan local databases, invoke CLIs or contact nodes during discovery; or
• restarts occasionally produce long windows where the process exists but control RPCs time out.

A larger probe timeout is not the first fix. It can mask event-loop starvation and delay recovery while chat, config and cancellation calls remain blocked behind optional work.

Safe rollout test

Use a staging Gateway with representative plugin and provider configuration but synthetic sessions:

1. record process start, readiness publication and the first successful health, config.get and chat.metadata responses;
2. issue those RPCs concurrently during memory and context initialization;
3. request the session catalog explicitly and prove only that request owns provider discovery;
4. prove no timer starts memory initialization merely because the Gateway has been ready for five seconds;
5. make the first explicit memory request and measure its cold latency without blocking unrelated control RPCs;
6. repeat chat.startup against a representative large roster and prove it consumes prepared projections;
7. load a synthetic large Workboard while polling health and a channel; and
8. repeat on cold and warm caches so lazy imports are not hidden by a development machine’s cache.

Track event-loop delay and per-RPC latency, not only total startup duration. A Gateway may take the same time to become fully warm while becoming far more usable because control-plane work can interleave.

Deployment acceptance

Avoid using production credentials merely to make staging discovery representative. Stub external providers or use isolated low-privilege test accounts.

Evidence and limits

The official merged PRs and landed commits establish the production ownership changes and focused lifecycle/concurrency tests. Upstream exact-host timings from #119377, #119742 and #118848 demonstrate severe failure modes but do not guarantee a latency reduction on every deployment. OpenClaw Academy did not benchmark an unreleased build on a multi-provider production Gateway or a large live board.

Collector IDs 40025/39900, 39607/39580, 39480/39438, 39485/39443, and 39409/39326 identify the earlier supporting merges and commits. IDs 40185/40107, 40441/40407, and 40680/40554 identify the new memory, chat-startup and Workboard corrections.

Bottom line

Optional work must not monopolize the Gateway. Stage the containing build until health, config and channels remain responsive during cold memory access, large-roster chat startup and large-board loading—and prove each expensive operation has a real request owner.