OpenClaw merged a Gateway reliability fix this morning that changes where task-retention maintenance does its work. PR #158235, titled "fix: keep task retention from blocking the gateway," moves retention reads and writes through the existing worker paths instead of letting maintenance wait synchronously on SQLite coordination in the Gateway event loop.
That sounds like plumbing, because it is. It is also the kind of plumbing that determines whether a busy OpenClaw host keeps feeling responsive while old task records are being cleaned up.
What Changed
The PR says task-retention maintenance could block the Gateway event loop while waiting for SQLite write coordination. The merged change keeps the user-visible retention behavior intact, but changes the execution path:
- A read worker prepares the selected task and fingerprint.
- A write worker revalidates the source and authority inside the transaction.
- A compact commit receipt can settle a lost reply without replaying the write.
- Publication reconciles indexes, activity, and flow effects before notifying observers.
- The superseded synchronous retention APIs and callers are removed.
The important point is that retention deadlines, cron-history limits, stored formats, and update behavior are not supposed to change. Operators should not need a migration or a new configuration flag.
Why It Matters
OpenClaw's Gateway has become the meeting point for task state, session state, cron history, publication, and channel delivery. Any maintenance routine that holds the wrong lane for too long can make unrelated work feel slower or stuck.
This PR narrows that risk by using the workers that already own the database boundary. The read side prepares what is needed, the write side rechecks that the prepared task is still current, and the publication path remains responsible for making the accepted result visible.
That extra revalidation matters. Moving work off the event loop is only useful if it does not weaken ownership. The PR explicitly calls out live-authority checks, newer-owner preservation, unknown-outcome handling, and retained retry obligations.
Evidence And Limits
The PR includes a direct regression claim: the coordinator-contention case passes with the worker cutover and fails on the original synchronous path at the responsiveness assertion. The author also lists retained proof across retention, publication, delivery, restore and replacement races, shutdown, and lost-result settlement.
There were several integration repairs along the way, including import-cycle, fixture, and restart-drain issues. The final branch also adopted a main-side fixture extraction instead of duplicating it. That kind of merge archaeology is not glamorous, but it is useful context for a change touching task ownership.
The measurements are bounded. Synthetic 64 KiB and 1 MiB profiles showed warm maintenance and publication timer gaps around 7 to 11 ms, but the PR does not claim deployed gains or a per-message memory bound.
The Takeaway
PR #158235 is a P1 reliability change for busy OpenClaw systems. Task retention should keep its existing semantics while doing less synchronous work on the Gateway event loop.
For administrators, the practical result is simple: maintenance should be less likely to get in the way of live Gateway work, without changing retention policy, task formats, or operator setup.