OpenClaw Hardens Memory Upgrades Against Rollback Lockout and Repeated 15-Second Recall Stalls

Three merged OpenClaw changes expose one operational lesson: a Memory upgrade is a state migration with a rollback and dependency-failure plan, not just a plugin refresh.

PR #116003 prevents upgraded recall metadata from making every registered agent database unacceptable to the previous binary during rollback. PR #116004 resets legacy session-backfill cursors so data removed by a rollback can actually be staged again. PR #112927 extends LanceDB’s recall cooldown breaker to automatic recall during prompt construction, where an embedder outage could otherwise stall every turn for the full 15-second timeout indefinitely.

Operators using Memory Core migrations, session backfill or LanceDB auto-recall should prioritize a containing version—but not perform a blind upgrade. Preserve the complete state boundary and test both forward and backward transitions.

The operator decision

All three changes are merged to main. The supplied evidence does not identify a packaged release containing them.

The rollback lockout

The upstream record for PR #116003 says the recall metadata upgrade could leave registered agent databases rejected by the prior binary after a downgrade. That is a persistent availability failure: rolling the executable back does not restore service if the older code refuses the upgraded database shape.

The fix keeps the database representation compatible with the rollback path. This matters even when the new feature works correctly. Rollback safety is part of migration correctness, not a concession that an upgrade is expected to fail.

Interpretation: “the process starts after downgrade” is not enough. Every registered agent database must reopen, and representative recall, write and synchronization operations must succeed on the old binary.

A rewind must permit a second forward pass

PR #116004 addresses legacy session-backfill entries created before a rewind journal existed. Rollback removed the staged memories and diary entries but retained their ingestion cursors. The next preview and re-apply therefore returned zero, converting an apparently successful rollback into a one-way migration.

The merged correction resets those legacy cursors and tracks complete rewind baselines. An acceptance test must prove the whole cycle:

1. preview the backfill;
2. apply it;
3. inspect synthetic memories and diary output;
4. roll it back;
5. confirm both data and progress state were rewound; and
6. preview and apply the same fixture again.

A rollback test that stops after deletion misses the exact failure this change fixes.

Embedder failure was on every prompt’s hot path

LanceDB already had a per-agent cooldown breaker for explicit memory_recall tool calls. Automatic recall runs earlier, in the before_prompt_build hook. According to PR #112927, that path did not share the breaker, so an unavailable embedder could consume the full 15-second auto-recall timeout on every prompt build without end.

The merged fix shares cooldown state between explicit and automatic recall. The desired degraded behaviour is bounded: the first proven failure may pay the timeout, subsequent turns should bypass the failing dependency during cooldown, and semantic recall should resume only through the defined recovery path.

This complements the separately merged keyword-fallback work already reported by OpenClaw Academy. Fallback controls retrieval capability; the shared breaker controls how often the prompt hot path is allowed to wait for a dependency known to be failing.

Safe migration test

Use copies and synthetic data, never the only production database:

1. Quiesce writes and capture the complete state family, including sidecars and plugin-owned files.
2. Clone it into an isolated environment with the same plugin configuration.
3. Upgrade to the candidate containing all required fixes.
4. Open every registered agent database and exercise harmless recall plus write operations.
5. Run a legacy backfill fixture through preview, apply, rollback and re-apply.
6. Downgrade the clone to the recorded old version and prove every database reopens.
7. Restore the candidate and confirm the second forward transition remains clean.
8. In a separate fixture, make the embedder unavailable and measure several prompt builds; verify waits are bounded by shared cooldown behaviour.
9. Restore the embedder and confirm normal recall returns without widening project scope or duplicating backfilled entries.

Never test downgrade compatibility by pointing two versions concurrently at the same live database.

Evidence and limits

OpenClaw Academy reviewed the official merged PR and commit records supplied by the repository collector, including upstream descriptions of the rollback rejection, retained cursors and repeated 15-second prompt-build stalls. The configured web backends could not retrieve the live PR pages during this run. We did not migrate a production Memory Core database, execute a legacy backfill or interrupt a real embedder.

The chronology and implementation claims are attributed to upstream. The migration matrix is our conservative operator guidance. No supplied evidence proves these commits are present in an official package.

Bottom line

Memory state has to survive three things: the upgrade, the downgrade and the second upgrade. It also has to fail quickly when semantic infrastructure is down. Track PRs #116003, #116004 and #112927 into a containing build, then prove the full cycle on copies before touching production.