Summary

• Problem: memory gateway/default managers could keep using an old sqlite handle after a CLI/status atomic reindex replaced the index file, so missing identity or dirty state could remain stuck until process restart. Search-first recovery could read the new DB but still keep stale dirty flags.
• Solution: cached managers now detect when the on-disk sqlite file has been atomically replaced, reopen the DB handle, refresh schema/meta/vector state, and carry the replacement-refresh signal into identity dirty cleanup even when search() is the first observer.
• ClawSweeper follow-up: replacement refresh now clears identity-only stale dirty state without clearing real pending memory/session work signaled by memory full-retry, pending watch paths, session full-retry, or session dirty files.
• Scope note: stale sqlite temp cleanup is intentionally left to fix(memory): clean stale reindex temp files #92891's guarded pid-lock cleanup path; this PR only handles cached-manager refresh after atomic replacement.
• What did NOT change: semantic indexes are still protected when the configured embedding provider is unavailable; this does not force a semantic rebuild, change provider identity rules, or delete temp sqlite files.
• Why it matters / User impact: a gateway should recover from memory index repair/rebuild work performed by CLI/status flows without requiring a restart.
• Fixes bug(memory): gateway cannot self-heal a missing index identity when chunks are already indexed #91167
• Refs memory-core main reindex thrashes, leaks main.sqlite.tmp files, and leaves memory_search paused after repair #90508

Real behavior proof

• Behavior or issue addressed: This patch covers local memory-index lifecycle failures: a cached live/default manager continuing to report missing identity after a CLI-style manager atomically replaces the same sqlite index with a valid FTS-only index; the search-first path where manager.search() is the first call after replacement; and the patch-quality edge where replacement refresh must clear identity-only dirty state without dropping unrelated pending memory/session dirty work.
• Real environment tested: Local Linux worktree /media/vdc/code/ai/aispace/openclaw-worktrees/issue-91167-90508, branch feat/issue-91167-90508.
• Exact steps or command run after this patch:

cd /media/vdc/code/ai/aispace/openclaw-worktrees/issue-91167-90508 && OPENCLAW_REPO=/media/vdc/code/ai/aispace/openclaw-worktrees/issue-91167-90508 node --import tsx /media/vdc/code/ai/aispace/openclaw-issue-91167-90508-evidence/memory-external-reindex-real-proof.mjs > /media/vdc/code/ai/aispace/openclaw-issue-91167-90508-evidence/memory-external-reindex-real-proof.out.json

cd /media/vdc/code/ai/aispace/openclaw-worktrees/issue-91167-90508 && OPENCLAW_TEST_FAST=1 node scripts/run-vitest.mjs extensions/memory-core/src/memory/manager.self-heal-missing-identity.test.ts -t "clears stale dirty state when search first observes a cli atomic reindex replacement"

cd /media/vdc/code/ai/aispace/openclaw-worktrees/issue-91167-90508 && OPENCLAW_TEST_FAST=1 node scripts/run-vitest.mjs extensions/memory-core/src/memory/manager.self-heal-missing-identity.test.ts -t "preserves pending memory and session dirty work"

cd /media/vdc/code/ai/aispace/openclaw-worktrees/issue-91167-90508 && OPENCLAW_TEST_FAST=1 node scripts/run-vitest.mjs extensions/memory-core/src/memory/manager.self-heal-missing-identity.test.ts

cd /media/vdc/code/ai/aispace/openclaw-worktrees/issue-91167-90508 && ./node_modules/.bin/oxfmt --check --threads=1 extensions/memory-core/src/memory/manager.ts extensions/memory-core/src/memory/manager.self-heal-missing-identity.test.ts

cd /media/vdc/code/ai/aispace/openclaw-worktrees/issue-91167-90508 && node scripts/run-tsgo.mjs -p tsconfig.extensions.json --noEmit

git -C /media/vdc/code/ai/aispace/openclaw-worktrees/issue-91167-90508 diff --check

• Evidence after fix: The independent Node proof below runs outside Vitest, imports the production memory manager, uses real SQLite files, warms a live/default manager, performs an external CLI-purpose force sync, and then verifies the same live manager object recovers without restart.

{
  "proof": "memory-external-cli-reindex-live-manager-refresh",
  "head": "f007c10b7cc47bda43951ee5f5fedac75eed590d",
  "runtime": "node --import tsx; production memory manager; real sqlite files; no Vitest",
  "scenarios": [
    {
      "scenario": "status-first",
      "firstObserver": "status",
      "sameLiveManagerObject": true,
      "before": { "identity": "missing", "dirty": true, "chunks": 1 },
      "after": { "identity": "valid", "dirty": false, "chunks": 1 },
      "recoveredWithoutRestart": true
    },
    {
      "scenario": "search-first",
      "firstObserver": "search",
      "sameLiveManagerObject": true,
      "before": { "identity": "missing", "dirty": true, "chunks": 1 },
      "after": { "identity": "valid", "dirty": false, "chunks": 1, "searchHits": 1 },
      "recoveredWithoutRestart": true
    }
  ],
  "allRecoveredWithoutRestart": true
}

Test Files  1 passed (1)
Tests  1 passed | 3 skipped (4)

Test Files  1 passed (1)
Tests  1 passed | 4 skipped (5)

Test Files  1 passed (1)
Tests  5 passed (5)
[test] passed 1 Vitest shard in 17.71s

All matched files use the correct format.
Finished in 22ms on 2 files using 1 threads.

node scripts/run-tsgo.mjs -p tsconfig.extensions.json --noEmit exited 0 with no stdout/stderr output.

git diff --check exited 0 with no whitespace errors.

• Observed result after fix: The cached manager no longer stays stuck on the old missing-identity sqlite handle after a CLI atomic reindex publishes a valid replacement. The real runtime proof covers both first observers with no unrelated pending work: status() refreshes to indexIdentity: valid and dirty: false, and search("Alpha topic") returns one hit before the subsequent status reports valid/dirty=false. The focused pending-dirty regression then seeds memory full-retry state plus session dirty files/full-retry state before the replacement; after refresh, identity becomes valid while dirty, memoryFullRetryDirty, sessionsDirty, sessionsDirtyFiles, and sessionsFullRetryDirty remain set. In both runtime-proof scenarios the same warmed live manager object is reused, so recovery happens without process restart. Stale temp cleanup is left to fix(memory): clean stale reindex temp files #92891's guarded cleanup path rather than duplicated here.
• What was not tested: No remote hosted gateway, desktop app, QMD daemon, or separate OS process gateway was run. The added proof uses a long-lived in-process default manager plus a separate CLI-purpose manager against real SQLite files to exercise the same cached manager / external atomic replacement boundary without mocking the memory manager.

Regression Test Plan

• Target test file: extensions/memory-core/src/memory/manager.self-heal-missing-identity.test.ts.
• Scenario locked in: A default manager with missing identity refreshes to valid after a CLI manager atomically replaces the sqlite file; the same replacement also clears identity-only stale dirty state when search() is the first post-replacement call; pending memory and session dirty work survives the replacement refresh.
• Why this is the smallest reliable guardrail: The tests use real sqlite files, real manager cache semantics, real search, and the existing atomic reindex path rather than mocking the state transition.

Merge risk

• Risk labels considered: public-contract related open PRs for bug(memory): gateway cannot self-heal a missing index identity when chunks are already indexed #91167/memory-core main reindex thrashes, leaks main.sqlite.tmp files, and leaves memory_search paused after repair #90508, local-only proof boundary, memory index lifecycle behavior.
• Risk explanation: The patch changes manager lifecycle behavior around sqlite handle refresh after an external atomic replacement and narrows dirty cleanup to identity-only stale state.
• Why acceptable: The refresh path only reopens when the main sqlite file identity changes on disk, preserves existing semantic-provider safety checks, and clears identity-only stale dirty state only when the manager previously had identity dirty state and the replacement index resolves as valid. Pending memory/session work remains dirty when backed by full-retry, pending watch-path, or session dirty-file state. A pending refresh marker only survives until the next identity refresh consumes it.

Root Cause

• Root cause: Safe reindex publishes by replacing the sqlite file, but an already-cached manager keeps its existing sqlite handle and in-memory identity/dirty flags. search() could refresh the handle before refreshIndexIdentityDirty() ran, consuming the one-shot replacement signal and leaving stale dirty/retry state in memory. The first cleanup pass also cleared all dirty/session retry state after a valid replacement, which fixed identity-only stale dirty flags but could drop unrelated pending memory/session work.
• Why this is root-cause fix: The cached manager now treats the on-disk sqlite file identity as the source-of-truth for whether its handle is stale, reopens when that identity changes, and carries that replacement signal until identity cleanup recomputes state from the replacement DB. Cleanup now recomputes only identity-derived stale dirtiness while preserving independently queued memory/session retry work.
• Fix classification: Root-cause reliability fix for memory index lifecycle refresh after external atomic replacement.
• Maintainer-ready confidence: High for the local sqlite/index lifecycle paths covered here. The patch is limited to manager open/refresh behavior and deterministic memory-core tests.
• Patch quality notes: The diff adds a dev/ino based DB replacement check, a pending dirty-cleanup marker, and regression tests for stale identity cleanup plus pending memory/session dirty preservation. It does not add sleeps, broaden provider compatibility, duplicate fix(memory): clean stale reindex temp files #92891's guarded temp cleanup, or relax semantic-index protection.
• Architecture / source-of-truth check: The sqlite index file identity and memory_index_meta_v1 remain the source of truth; the live manager now refreshes its in-memory view from that source instead of trusting stale process-local state.