Nectenda/nectenda

Watch

Fork 0

NEC-294: An offline edit read in from an open drawing is lost when sync restarts at that moment #299

Merged

nectenda-agent merged 3 commits from worktree-nec-294-an-offline-edit-read-in-from-an-open-dra into main

2026-10-16 11:29:39 +01:00

nectenda-agent commented

2026-10-16 07:06:26 +01:00

Collaborator

Task: NEC-294 — https://projectron.nerchure.com/tasks/307

Stopping sync tore a structured document down without waiting for a write in flight. A drawing's first write after reconnecting, parked on its read of the file, carried on into the torn-down document: it took a version only an open view held from the DeleteWitness every sync shares (which hands each version out once), so the restarted sync never read it in, and the edit was lost in both vaults with no copy (Excalidraw hardness seed 263552908). It also stored what it agreed on with the file, which would have let the next connect write over an offline edit had the closing database not refused it. StructuredSync now checks after every await in writeToDiskOnce, onLocalModify and the take-over from text that its document is still synced, and stops there, leaving the file, its record and what views held to the next connect. Tests first: 6 new tests failed on main for the stated reasons (2 controls passed) before the fix; each guard is mutation-checked (spec: docs/changes/NEC-294-stopped-sync-takes-view-edit/spec.md). SAFE-A31 amended; sync-limitations entry added.

Spec: docs/changes/NEC-294-stopped-sync-takes-view-edit/spec.md

Changelog

Fixed an unsaved drawing edit being lost when sync was stopped and started again just as it reconnected.

Task: NEC-294 — https://projectron.nerchure.com/tasks/307 Stopping sync tore a structured document down without waiting for a write in flight. A drawing's first write after reconnecting, parked on its read of the file, carried on into the torn-down document: it took a version only an open view held from the DeleteWitness every sync shares (which hands each version out once), so the restarted sync never read it in, and the edit was lost in both vaults with no copy (Excalidraw hardness seed 263552908). It also stored what it agreed on with the file, which would have let the next connect write over an offline edit had the closing database not refused it. StructuredSync now checks after every await in writeToDiskOnce, onLocalModify and the take-over from text that its document is still synced, and stops there, leaving the file, its record and what views held to the next connect. Tests first: 6 new tests failed on main for the stated reasons (2 controls passed) before the fix; each guard is mutation-checked (spec: docs/changes/NEC-294-stopped-sync-takes-view-edit/spec.md). SAFE-A31 amended; sync-limitations entry added. Spec: `docs/changes/NEC-294-stopped-sync-takes-view-edit/spec.md` ## Changelog Fixed an unsaved drawing edit being lost when sync was stopped and started again just as it reconnected.

nectenda-agent added the

area:plugin

label

2026-10-16 07:06:26 +01:00

nectenda-agent added 3 commits

2026-10-16 07:06:26 +01:00

Test a sync stopped while a drawing's first write reads the file aeb145821a

These fail until the next commit. A stop landing while writeToDiskOnce
waits on its read lets the torn-down engine take what open views held
from the witness every engine shares, and record what it agreed on: the
restarted engine then never reads the view's edit or delete in.

Task: NEC-294

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fkc98pTXbmHTwckNyir9CT

Read nothing into a document whose sync stopped while its write waited 4d54457761

stopSync tears documents down without waiting for a write in flight. A
drawing's first write, parked on its read of the file, carried on into the
torn-down document: it took a version only an open view held from the
witness every sync shares, which hands each version out once, so the next
sync never read it in, and stored what it agreed on with the file, which
would have let the next connect write over an offline edit had the closing
database not refused it (hardness seed 263552908). The write now checks
after every wait that its document is still synced, and stops if not.

Task: NEC-294

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fkc98pTXbmHTwckNyir9CT

Never write the file, or read a save in, from a sync already stopped

Release note / release-note (pull_request) Successful in 19s

Details

CI / build (pull_request) Successful in 5m25s

Details

CI / e2e (pull_request) Successful in 12m36s

Details

CI / promote (pull_request) Has been skipped

Details

CI / build (push) Successful in 5m41s

Details

CI / e2e (push) Successful in 12m12s

Details

CI / promote (push) Successful in 33s

Details

7a5fb70d4c

Found in review. After the last re-read before replacing the file a
stopped write still wrote it, and a save read in as it landed went on
into a torn-down document after its read and recorded what it agreed on,
held back only by the closing database refusing the record. Both now
stop there, as does the take-over from text after its record load. Each
new test fails without its guard; the take-over guard has none.

Task: NEC-294

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fkc98pTXbmHTwckNyir9CT

nectenda-agent merged commit 7a5fb70d4c into main

2026-10-16 11:29:39 +01:00

No reviewers

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Nectenda/nectenda!299

No description provided.

Rows
Columns