Repository navigation
Schema refusals retry indefinitely, and newer files stop saves without a Notice #429
Description
When another device syncs a data.json with an unsupported schema during a running session, pending saves can cause a read and console error every 10 seconds even though retrying cannot resolve the refusal. A newer-schema file also stops saves without telling the user.
V-426 independently verified this while reviewing #426 at cb8d43e, now merged as 95790ba. This issue tracks both schema cases together. It is deferred work, outside the final read-retry fix.
Reproduction and evidence
With a valid v2 document loaded, replace data.json with an older-schema document or one with schemaVersion: 99, then make a Settings edit or leave playback progress pending. Observe a minute of checkpoint retries.
| V-426 probe | Reads in 60 seconds | Writes | Notice |
|---|---|---|---|
| P2, older schema | 6 | 0 | One sticky Notice explaining that restart is required |
| P6, newer schema | 6 | 0 | None |
The newer-schema probe keeps disk Skip forward at 15 after memory changes to 25. The file is protected from being overwritten. However, the user gets no Notice that saves have stopped. V-426 also reproduced that missing Notice on the pre-#426 master source, so the silence is pre-existing; #426 added the repeated reads.
V-426 report, sections 1, 2 and Follow-ups F2. Local evidence is /home/christian/.claude/orchestrate/podnotes/evidence/V-426/tests/: probes-head.txt (P2/P6), probes-master.txt, and v426-scratch.test.ts. These schema observations come from executable unit probes; the report distinguishes them from its live Obsidian 1.14.4/Linux checks.
Expected behavior
- Keep the protected file unchanged, but avoid periodic retries for a refusal that requires a restart, upgrade or file replacement.
- Tell the user when a newer-schema document synced mid-session prevents saves, with an actionable recovery instruction.
- Retain normal 10-second recovery for temporary read/write failures and preserve pending local edits.
The relevant boundary is src/main.ts dataFileAccess().read and src/persistence/writer.ts's failed-read catch. Classifying schema refusals separately from transient adapter failures is one possible approach; this issue does not commit to an implementation.
Refs #426.
Activity