MCP edit leaves live state ahead of disk; watchdog is preempted by delete

[qadsawee79]

Summary

On 0.78.0, an MCP edit is applied to the live document but never written to disk. The server's own staleness sweep detects the divergence every minute but never flushes it (divergent=1, forced=0). A retry of the same edit then returns Text not found in document, because the live doc already has the change. A later MCP delete returns HTTP 200, but the file stays on disk.

The same write → edit → delete round-trip passed on 0.76.1 (2026-09-20) and 0.77.1 (2026-09-22) on the same machine and vault. This looks like a regression in 0.78.0.

Environment

• OS: Windows 11 Pro
• @inkeep/open-knowledge: 0.78.0 (npm global, stable latest)
• Node: v26.7.0
• Project: an Obsidian vault, ~780 clippings, git repo with a remote
• Server started fresh by the MCP client after upgrading from 0.77.1

Steps

1. Fresh server on 0.78.0 (first start after upgrade).
2. MCP write: { document: { path: "ok-write-test-0.78.0", content: "# OK 0.78.0 write test\n\nline one." } }
   • Client timed out. File landed on disk ~4 minutes later (log: [persistence] Wrote .../ok-write-test-0.78.0.md (33 bytes)). OK.
3. MCP edit: { document: { path: "ok-write-test-0.78.0", find: "line one.", replace: "line one, edited." } }
   • Client timed out. Log shows [agent-write] applied agent markdown write. No [persistence] Wrote follows.
4. Waited 3+ minutes. Disk still line one.. exec("cat ok-write-test-0.78.0.md") also returns line one..
5. Retried the same edit → Error: Text not found in document.
6. MCP delete of the same doc → client timeout; log shows POST /api/delete-path 200. File is still on disk minutes later.

Expected

The edit is persisted to disk (as on 0.76.1 / 0.77.1), or the tool reports a failure. delete removes the file when it returns 200.

Actual

The live doc and disk diverge silently. The retry error ("Text not found") hides that the change was never saved. delete reports success but does not remove the file.

Log excerpt (.ok/local/logs/server-current.jsonl, one server pid, times UTC)

12:52:52 persistence: [persistence] Wrote ~/Documents/Second Brain/ok-write-test-0.78.0.md (33 bytes)
12:52:52 agent-sessions: [agent-write] applied agent markdown write      <- write
12:52:52 shadow-lock: Stale lock detected (pid=46276, host=...) — replacing
12:53:21 agent-sessions: [agent-write] applied agent markdown write      <- edit (no "Wrote" after this)
12:53:53 persistence-staleness: sweep complete  scanned=1 divergent=1 forced=0 stoodDown=0
12:54:53 persistence-staleness: sweep complete  scanned=1 divergent=1 forced=0 stoodDown=0
12:55:53 persistence-staleness: sweep complete  scanned=1 divergent=1 forced=0 stoodDown=0
12:56:53 persistence-staleness: sweep complete  scanned=1 divergent=1 forced=0 stoodDown=0
12:57:18 http: Text not found in document.                                 <- edit retry
12:57:53 persistence-staleness: sweep complete  scanned=1 divergent=1 forced=0 stoodDown=0
12:58:23 agent-sessions: closing all sessions for doc
12:58:53 api: POST /api/delete-path 200                                    <- delete; file remains on disk
12:58:53 persistence-staleness: sweep complete  scanned=0 divergent=0 forced=0 stoodDown=0

Also seen at startup: [agent-presence] __system__ document not found — presence updates will be dropped and [cc1] __system__ document not found at emitDiskAck — dropped.

Notes

• The server process was busy during this window (~600 CPU-seconds in ~9 minutes), still building its first index after the upgrade. The bug may only show during that warm-up, but the staleness sweep saw the divergence for 5 minutes and never forced a write.
• Related earlier reports: lint({ fix: true }) reports "Fixed N problems" but does not persist the change to disk #1511 (lint fix not persisted, fixed), Windows: server unresponsive ~60-90s after every ok start — git block-timeouts are collateral, not the cause #1268 (slow boot on Windows).