NEC-297: A drawing opened as sync writes it can fall back to a Markdown view (Excalidraw 2.27) #301

Merged
nectenda-agent merged 6 commits from worktree-nec-297-a-drawing-opened-as-sync-writes-it-can-f into main 2026-10-17 00:59:43 +01:00
Collaborator

Task: NEC-297 — https://projectron.nerchure.com/tasks/310

A drawing opened just as sync writes it could come up as Markdown on Excalidraw 2.27.3, about once in fifty CI runs (FLAKE-15). Instrumented first: the diagnostic log now says when a drawing stops showing in its view and what the tab shows instead, the multi-vault test reports the tab's view types and console output as it opens, and an excalidraw-open-write probe rewrites a drawing inside its load with this plugin disabled (175 opens, never reproduced). A 60-iteration runner soak (run 1482) caught it: B's first write landed ~40 ms after its view was found still loading, Excalidraw logged an error, and ~240 ms later the tab was Markdown. Fix, chosen by the user: a structured write waits while an unbound open view of the file is still loading it, for at most 3 s, then writes anyway; the change waits in the document (new rule SAFE-A43). A review found the hold's start went stale when a hold ended another way; a hold not renewed within three debounces is now over, with a regression test.

Spec: docs/changes/NEC-297-excalidraw-markdown-fallback/spec.md

Changelog

A drawing opened at the moment sync updates it no longer sometimes opens as plain Markdown.

Task: NEC-297 — https://projectron.nerchure.com/tasks/310 A drawing opened just as sync writes it could come up as Markdown on Excalidraw 2.27.3, about once in fifty CI runs (FLAKE-15). Instrumented first: the diagnostic log now says when a drawing stops showing in its view and what the tab shows instead, the multi-vault test reports the tab's view types and console output as it opens, and an excalidraw-open-write probe rewrites a drawing inside its load with this plugin disabled (175 opens, never reproduced). A 60-iteration runner soak (run 1482) caught it: B's first write landed ~40 ms after its view was found still loading, Excalidraw logged an error, and ~240 ms later the tab was Markdown. Fix, chosen by the user: a structured write waits while an unbound open view of the file is still loading it, for at most 3 s, then writes anyway; the change waits in the document (new rule SAFE-A43). A review found the hold's start went stale when a hold ended another way; a hold not renewed within three debounces is now over, with a regression test. Spec: `docs/changes/NEC-297-excalidraw-markdown-fallback/spec.md` ## Changelog A drawing opened at the moment sync updates it no longer sometimes opens as plain Markdown.
Excalidraw 2.27 swaps a view whose load failed for the Markdown view of
the same file. On CI that came as this vault's first write of the drawing
landed, and nothing in the log said the view had changed type.

Task: NEC-297
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019ah6oyqpiQSZ92LKu21Wbv
The multi-vault test now says what the tab showed while it waited for
Excalidraw's API, and what reached the console. The excalidraw-open-write
probe rewrites a drawing at a range of delays into its view's load, with
this plugin disabled, and says what the tab ends up showing.

Task: NEC-297
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019ah6oyqpiQSZ92LKu21Wbv
Task: NEC-297
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019ah6oyqpiQSZ92LKu21Wbv
Soak run 1482 caught the fallback, and Excalidraw's error came out as
[object Object].

Task: NEC-297
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019ah6oyqpiQSZ92LKu21Wbv
On Excalidraw 2.27.3 a drawing written as its view loaded it came up as
Markdown, about once in fifty runs on the CI runner. The write stepped
aside only for a bound view, and a view still loading is not bound yet.
It now waits while one is loading, for at most three seconds, the change
held in the document meanwhile (SAFE-A43).

Task: NEC-297
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019ah6oyqpiQSZ92LKu21Wbv
Give a view that starts loading again a hold of its own, and test the hold's log
All checks were successful
Release note / release-note (pull_request) Successful in 16s
CI / build (pull_request) Successful in 5m33s
CI / e2e (pull_request) Successful in 12m13s
CI / promote (pull_request) Has been skipped
CI / build (push) Successful in 6m23s
CI / e2e (push) Successful in 12m33s
CI / promote (push) Successful in 35s
ebbefe693b
Review of the hold: its start was cleared only by a write that got past
it. One that ended any other way, the view binding or an edit holding the
write first, left the start behind, and a view loading later was written
under at once. A hold not renewed within three debounces is now over.
The hold's two log lines are asserted, and the probe counts in the docs
say how they were made.

Task: NEC-297
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019ah6oyqpiQSZ92LKu21Wbv
Sign in to join this conversation.
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!301
No description provided.