Deleted CRDT-tracked files reappear on every reconcile because tombstones never reap

[stephangrobler]

YAOS plugin version

2.1.1

Server deployment commit SHA

Unknown, server deployed via Cloudflare Worker at .workers.dev

Relevant logs or error text

logs/2026-09-18/boot-nWCiZqQ0XydRK6.ndjson, ~13:16:47Z, after the files below had already been deleted (deletion confirmed committed to the vault's git history):

flushWrite: "2 Areas/Logs/Events/Foodies at Janine and Rickus - 2023-06 (YAOS conflict - crdt from stephan-home-pc 2026-08-23T23-50-39Z).md" unchanged, skipping
flushWrite: "2 Areas/Logs/Daily Journal/2026-08-17 (YAOS conflict - crdt from stephan-home-pc 2026-08-23T23-50-39Z).md" unchanged, skipping
flushWrite: "2 Areas/Logs/Daily Journal/2026-08-04 (YAOS conflict - crdt from stephan-home-pc 2026-08-23T23-50-39Z).md" unchanged, skipping

(14 files total in this batch, all previously deleted, all rewritten.)

serverTrace snapshots, taken roughly every 15 seconds over several hours:

{
  "event": "tombstone-reap",
  "metaEntries": 6112-6126,
  "tombstones": 1154,
  "alreadyReaped": 0,
  "withBody": 1154,
  "reaped": 0,
  "withinGrace": 1154,
  "unknownAge": 0,
  "conflicted": 0,
  "remaining": 0
}

reaped is 0 and withinGrace equals the full tombstone count in every snapshot across the session. tombstonedPathCount in client state stays fixed at 1154 across multiple reconciles and restarts, independent of what got deleted or resynced in that window.

Live check against this room's own diagnostic endpoints today (/vault/:id/snapshots/status, /vault/:id/snapshots, /vault/:id/debug/recent) all return HTTP 200, so the Durable Object is not wedged the way it was in #73. But the latest snapshot response includes:

"markdownFileCount": 0

despite the room tracking roughly 4,972 markdown paths. That's the same unexplained anomaly noted at the end of #73 ("every snapshot lists md:0 even though the room holds 217 markdown files that sync fine") after that room's full worker-delete-and-reseed recovery. Different room, same symptom.

What you did

1. Delete a tracked markdown file. Reproduced via a raw filesystem move and via Obsidian's own delete UI, with the same result either way.
2. Restart Obsidian, or wait for the next authoritative reconcile.
3. flushWrite recreates the file on disk with its original content and path, because the CRDT still holds it as live: tombstones for this room appear to never leave their grace period and finalize.

One file in the same batch has corrupted YAML frontmatter, including literal unresolved git merge markers in the body, and does not reappear silently. The frontmatter safety guard catches its flushWrite and blocks it (yaml-parse-error), surfacing a user notice. flushWrite itself works correctly; the defect looks isolated to tombstone finalization.

Deletion is non-durable for the life of this bug: duplicate and junk files cannot be permanently removed, they return on every restart.

Related issues

• [Bug] Conflict-artifact loop from one note wedged the room's Durable Object (all DO routes 500, snapshots stopped) #73 — same room-corruption family (conflict-artifact loop, wedged DO). This room isn't wedged (all diagnostic routes return 200), but shares [Bug] Conflict-artifact loop from one note wedged the room's Durable Object (all DO routes 500, snapshots stopped) #73's unexplained markdownFileCount: 0 snapshot anomaly, which suggests the underlying issue wasn't fully resolved by the 2.1.1 hotfix, or resurfaces independently.
• [Bug] Note gets duplicated while typing if another plugin writes to it (2.1.1) #74, [Bug] Startup reconcile writes a '- disk' conflict artifact for a fresh note that's open and being typed in (2.1.1) #77 — same conflict-artifact-generation family, both open on 2.1.1.

[stephangrobler]

Separate but related symptom on the same install (2.1.1), also unresolved: the attachment download gate never opens.

Status bar shows Connected ↓0/73 (blob/attachment downloads queued, 0 completed) and stays there indefinitely. Checked the live state log across multiple restarts:

• Both readiness signals the gate depends on do fire: Blob download gate: workspace layout ready and Blob download gate: startup ready (startup-complete) both appear in the log.
• Blob reconciliation [authoritative]: 0 uploads, 73 downloads, 0 skipped repeats unchanged across many reconcile passes, hours apart, multiple restarts.
• "Download gate opened" never appears in the log, on any boot checked, even after both readiness signals are confirmed true.
• Used the "Refresh attachment capability" settings action (refreshServerCapabilities + refreshAttachmentSyncRuntime) as a manual workaround. No effect: no new log line from the refresh itself, reconcile output unchanged, gate still never opens.

Given both downloadGateLayoutReady and downloadGateStartupReady are confirmed true but the gate still doesn't open, this looks like maybeOpenDownloadGate either isn't being invoked at the point both flags become true, or this.blobSync is null at that moment (the whole check short-circuits silently since it's guarded by this.blobSync && (...)). Happy to grab a debug trace bracketing a fresh boot if useful.

[kavinsood]

Hey! Thanks for opening this issue. I'm currently away from laptop.

Just for funsies, can you try using the yaos3 branch? Just point your agent towards the branch, ask it to deploy the server, build the client plugin, and replace it in your vault.

I'd love to hear your experience with these issues on it. As for the issues you mentioned, I'll triage and put out a patch soon.

[stephangrobler]

Hi Kavin,

Update on testing yaos3. I made a disposable copy of my vault, cloned the repo, deployed a separate isolated server (yaos3-test, kept fully apart from my production Worker), built the plugin, claimed the new server, and enrolled the copy as owner — same steps you described.

Didn't manage to cleanly reproduce the original tombstone/reappearing-files issue, but ran into four separate problems along the way:

1. Status bar gets stuck on "Error" permanently, even after a successful reconnect. connectionStateLatch.recover() only runs inside the fully-successful initSync() path, so one startup exception latches it and it never clears on a normal reconnect afterward.

2. A client's bootstrap cursor can get stuck ahead of the server for good. Got a recurring vault request failed (400) from settleRootThrough — client asking to settle through a sequence number higher than the server's own current one. Happened right after I deleted a file and quit the app immediately, and it recurred identically across three restarts. The only fix was manually deleting the client's IndexedDB via DevTools; no in-app command touched it.

3. The recovery commands themselves can become unreachable. teardownSync() nulls vaultSync/vaultDatabase, and both "Reset local cache" and "Nuclear reset" just refuse to run ("Sync not initialized") if those are null — which is exactly what happened to me after 2. Ended up with no working recovery command in the UI at all.

4. Nuclear reset fails outright on a normal-sized vault. Once it was reachable again, running it threw net::ERR_INSUFFICIENT_RESOURCES. It fires one unbatched request per tracked file through Promise.all (currentBodyEpoch → server.currentHead) — for my ~4,800 files that's ~4,800 requests at once, which the browser choked on.

One more thing worth mentioning: I also run Obsidian Git alongside YAOS, with auto-merge pulling from a remote every 10-30 minutes. There's a real chance that's what's actually behind the original reappearing-files report — a merge landing at the wrong moment could write a tombstoned file straight back to disk, and YAOS has no way to tell that apart from a real user action.

Let me know if you'd rather have these as separate issues — happy to log them individually.

[stephangrobler]

Hi Kavin,

Couple of follow-ups since my last comment.

First, a correction on my end: I originally said I was testing against my "2.1.0" production setup, but production is actually on 2.1.1 — that's also what #78 itself was filed against, so no correction needed there, just wanted to flag I'd misstated it in my own notes. Also realized 2.1.1 already includes the fix for #73 (the conflict-artifact loop) — I've actually got the artifact files from that one sitting in my vault from before the fix, so can confirm that bug was real and 2.1.1 does seem to have stopped it recurring. Just didn't fix the tombstone-reap issue, since it's a separate mechanism.

Second, out of curiosity I tried pointing an unmodified 2.1.1 client at my yaos3-test server (schema 8) just to see what would happen. It failed cleanly and safely — no crash, no data touched. It logged "Token not configured" (didn't recognize the schema-8 settings shape) and then independently caught the schema mismatch itself: "This server requires schema version 8. Update this plugin before syncing." Wasn't expecting anything different, but good to confirm the compatibility guard holds up even against a real, older client hitting a real incompatible server.

Nothing further to add beyond the four from before — just closing the loop on those two side questions.