Publish the restoring marker by rename so a torn write cannot unblock a half-purged database

[cb1kenobi]

beginRestore() opened the restoring marker with openSync(markerPath, 'w'), which truncates before the database name is written, and scanBlockedRestores() skips any marker whose first line is empty. On a recovery attempt — over a directory an earlier restore may have half-purged — that marker is the only thing keeping the directory from loading, so a crash in the truncate-to-write window left a half-purged database that loads as healthy on the next boot.

The marker is now published temp → fsync → rename → parent fsync, so the path only ever holds the previous content or the complete new content, and an intact marker is not rewritten at all: the content a recovery attempt would write is the content already there, so the write was pure risk.

For the human reviewer

1. An intact marker is reused rather than rewritten, so its timestamp stops tracking the latest attempt. Nothing parses the second line, and the original interrupted restore's time is arguably the more useful one, but it is a visible change for anyone reading the file by hand. The alternative — rewriting it — is the defect.
2. "Intact" means the first line equals the database directory name, not merely non-empty. A write torn mid-name leaves a prefix that resolves to a different metadata key and therefore blocks nothing, so a prefix is repaired rather than preserved. This also repairs debris left by the buggy version on upgrade.
3. The temp name is fixed rather than unique. The caller holds the exclusive per-database restore lock, so a temp left by an earlier crash is this database's own debris and is simply overwritten. It deliberately does not end in .restoring, which is how scanBlockedRestores selects markers.

Changes

• dataLayer/restoreMarker.ts — publishRestoringMarker writes a temp sibling, fsyncs it, renames it over the marker path and fsyncs the directory; markerIsIntact compares the marker's first line against the database directory name; and beginRestore publishes only when there is no intact marker, flushing the directory either way.

Verification

Route (a) — extended unitTests/dataLayer/restoreMarker.test.js, the suite that already covers this module, and ran it through npm run test:unit:backup (the repo's focused backup suite: 128 passing). Fails-on-base check performed: with the source reverted and the tests kept, leaves an intact marker byte-identical on a recovery attempt and overwrites a temp file a crashed write left behind both fail, and pass on the branch.

The test file is unitTests/dataLayer/restoreMarker.test.js, which gains cases for the byte-identical recovery marker, the torn-name repair, the empty-marker repair, and the absence of temp debris.

Complexity: medium

---

Cross-model review. Reviewed against main by codex gpt-6-astra (xhigh), Gemini 3.1 Pro and cursor-composer — three outside families. The round found a real defect: preexisting was sampled before the restore lock was acquired, so an attempt that raced a crashing predecessor could believe an inherited marker was its own and clear it, unblocking a half-purged directory — the exact failure this PR exists to prevent. Fixed in ac0708b7. One reported blocker was not adopted: the claim that the temporary file is never flushed before rename is incorrect, fsyncSync(fd) sits between writeSync and closeSync. The Harper-domain adjudication leg was killed (SIGKILL), so findings were triaged by the author rather than adjudicated.

_{Review-Coverage: authored=claude; ran=gemini,cursor-composer,codex; blocked=domain(exit--1); declined=cursor-grok; rounds=1; full=1 @ ac0708b}

_{Human-Review-Need: 4 @ ac0708b}

[gemini-code-assist]

Code Review

This pull request introduces atomic publishing of the database restoring marker to prevent torn writes from leaving invalid or empty markers. It implements a temporary file write followed by a rename and directory fsync, and adds a check to ensure existing markers are intact before reusing them. Additionally, comprehensive unit tests have been added to verify these behaviors under various failure scenarios. I have no feedback to provide as there are no review comments to address.

[claude]

Reviewed; no blockers found.

[kriszyp]

Looks great!

_{🤖 Reviewed with Codex}