OpenClaw merged an update-path performance fix in PR #154548: update canaries now defer Gateway maintenance work that only matters after the candidate becomes the serving Gateway.
The change is aimed at a specific but important phase of OpenClaw updates. Candidate validation runs under the installed updater's deadline, and it only needs enough startup behavior to prove the candidate can load, pass required checks, and answer readiness probes.
What changed
The shipped --update-canary mode already suppressed some autonomous work, but the suppression happened too late. This PR applies the existing candidate flag earlier, before session catalogs, worker recovery, background lifetimes, and maintenance owners are prepared.
During canary validation, OpenClaw now skips or defers:
- Session catalog hydration
- Worker store, runtime, and placement preparation
- Startup maintenance
- Task and skill background startup
- Other serving-only Gateway work
Required configuration, ownership, schema checks, migration admission, and actual plugin runtime loading still run. That distinction is important: the canary still validates the parts that determine whether the candidate can safely become active.
User impact
Operators should see update canaries reach readiness with less startup work in the way. The PR does not add new CLI flags, environment variables, configuration surfaces, dependencies, or schema changes.
The serving Gateway prepares the deferred work normally after activation. A warning records the deferral so operators have an audit trail rather than a silent shortcut.
The PR also updates troubleshooting guidance around older updater deadlines, including manual package-manager install, Doctor, and restart recovery for the fixed timeout path.
Performance notes
The PR reports a matched packaged-build measurement on a Linux Testbox with ten agents, ten agent databases, and a 222.4 MiB main database at Gateway spawn.
In that synthetic pair, candidate readiness moved from 7.262 seconds to 6.941 seconds. The absolute improvement is modest because the baseline already met the requested 90-second target, but the architectural improvement is the real point: canary startup no longer spends part of its bounded window preparing state it will not use.
The author also tested the actual published openclaw@2026.9.4 updater in a private npm prefix. That public updater installed the candidate and completed the full update flow successfully, while retaining the released 300-second canary clamp. Candidate readiness in that cell was reported at 6.134 seconds.
Validation notes
The PR includes a real Gateway regression proving the original code failed before bind in the relevant synthetic plugin path, while the patched code returned HTTP 200 from both /startupz and /readyz without invoking the deferred owners.
Existing canary suites, Gateway owner suites, schema-refusal coverage, built canary integration, package integrity checks, formatting, changed checks, and review all passed. The resulting patch keeps normal Gateway startup on its existing path while making candidate validation narrower and more purposeful.