OpenClaw merged PR #119710, "fix(memory): keep gateway responsive after startup", a P1 memory-core fix for post-ready Gateway stalls.
The symptom showed up after the Gateway said it was ready. Operators could still see multi-second delays in health, first-device, and config.get RPCs because memory-core started unsolicited index initialization five seconds later.
That timing made the system feel misleading. Readiness is supposed to mean the operator can start asking basic questions of the Gateway. A background memory warmup that blocks ordinary health and config calls turns "ready" into "ready, unless a hidden startup task just woke up."
Demand-Driven Memory Boot
The previous repair delayed the contention window. PR #119710 removes it. OpenClaw deletes the startup memory-manager warmup and keeps initialization demand-driven at the memory owner boundary.
Builtin memory search already has a contract for this: when the index is empty, the first real search performs the needed bootstrap and schedules dirty refreshes through the search path. QMD keeps its backend-owned boot policy.
That means the cost of memory initialization is paid by the operation that actually needs memory, not by unrelated Gateway calls shortly after readiness. The production delta is also lean: the PR removes startup timer, lifecycle generation guards, warmup sync, and obsolete tests for a net reduction of 72 lines.
Why It Matters Operationally
Health checks and configuration reads are often used by supervisors, setup flows, mobile clients, and automation. If those calls stall after readiness, the user experience can look like a flaky Gateway even when the process is alive.
The fix narrows ownership. Memory initialization belongs to memory operations. Basic Gateway liveness and configuration should remain responsive unless they themselves need the memory subsystem.
That distinction is especially important for self-hosted OpenClaw deployments where the same small machine may be running Gateway, plugins, local model helpers, and background jobs. Avoiding unsolicited startup work keeps the control plane easier to reason about.
User Impact
Users should see a more stable post-start experience. The Gateway can report ready and continue answering health, first-device, and config RPCs instead of pausing later for background memory synchronization.
The first memory search may still pay a bootstrap cost if the index is empty. That is a clearer tradeoff: memory work happens when a user asks for memory work, and the existing search contract owns the refresh behavior.
No memory configuration, storage format, search contract, or QMD boot behavior changes with this PR.
Evidence
PR #119710 includes packaged sourcePerformance probe results comparing current main with the candidate across five measured samples plus a warmup. The reported improvements were substantial: connected health --json fell from a 3,110 ms p50 to 801 ms, fresh-device health --json fell from 1,499 ms to 767 ms, and config get gateway.port fell from 5,249 ms to 1,113 ms.
All 15 candidate samples passed, and the Gateway stayed responsive through the post-ready window. The PR also reports exact-head GitHub performance proof, diagnostic repeat coverage, clean shutdown behavior, focused tests, formatting, linting, and git diff --check.
For operators, this is the kind of fix that makes OpenClaw feel less surprising. Readiness should not be followed by a hidden performance cliff, and memory-core now waits for a memory request before doing memory work.