OpenClaw merged PR #112424, "fix(sessions): keep gateway responsive while large transcript archives are built", a P1 availability and session-state fix for SQLite-backed session lifecycle cleanup.
The bug affected cleanup paths such as reset, delete, eviction, and maintenance. If a session had a large transcript, OpenClaw could temporarily stall the Gateway event loop while building and publishing the transcript archive.
That is a bad tradeoff for an always-on personal agent. Archiving before deletion is the right safety fence, but it should not monopolize the Gateway or keep unrelated work waiting while a large transcript is compressed.
Worker-Owned Archive Materialization
PR #112424 moves lifecycle transcript-archive materialization into a dedicated Worker. The design keeps the existing archive format and preserves the archive-before-delete rule, but shifts the expensive materialization step away from the main Gateway event loop.
The lifecycle flow now has three phases:
- Plan the cleanup while holding the per-store writer lane.
- Release that lane while a Worker materializes and durably publishes the archive.
- Reacquire the lane for final validation and deletion.
That final validation is important. The write transaction rereads authoritative references and snapshot state before deleting lifecycle rows. In other words, OpenClaw still refuses to reclaim transcript or lifecycle rows covered by the plan unless a verified archive exists.
Bounded Queueing
The PR also adds a process-local keyed FIFO so only one lifecycle archive Worker runs at a time for this path. That avoids multiplying whole-buffer memory pressure across multiple Worker heaps while keeping unrelated Gateway work responsive.
Failed jobs release the queue for future work. Existing manual compaction paths are unchanged, and the PR deliberately scopes this phase to lifecycle archive materialization.
There is also a privacy-minded incognito behavior. Automatic lifecycle maintenance for an in-process incognito database now skips transcript archive creation at the canonical planner. Maintenance can still prune in-memory rows, but it does not try to send an unreachable in-memory database to a Worker or publish private transcript content to disk.
User Impact
Users with large session histories should see fewer Gateway stalls during cleanup. Resetting or deleting a heavy session can still take real work, but that work no longer needs to block the main Gateway event loop or hold the per-store writer lane while compression and publication run.
The archive safety model stays intact. OpenClaw still plans, validates, publishes, and only then deletes. The change is about where the expensive work happens and how the owner lane is held, not about weakening data-retention safeguards.
That makes this a meaningful reliability improvement for long-lived agents. The more useful an agent becomes, the more transcript history it accumulates. Lifecycle maintenance needs to scale with that reality.
Evidence
PR #112424 reports focused Vitest coverage for normal archives, queue serialization, queue release after failure, read-only Worker database opening, row-count validation, hash validation, archive-before-delete enforcement, race detection, mutation aborts, missing-agent validation, and incognito cleanup behavior.
It also reports a manual responsiveness harness showing 1 ms health-probe latency during a 40,000-event deletion. The Worker stress harness covered 40,000 transcript events and produced about a 4.8 MB gzip archive.
For operators, the headline is straightforward: OpenClaw can keep the Gateway responsive while it does the careful archival work required before session lifecycle cleanup.