Back-of-note embeddable can initialize as the full drawing during concurrent updates
Summary
During aggressive multi-view editing, a same-file back-of-the-note embeddable can rarely initialize as the complete Excalidraw drawing instead of its linked Markdown section. The element link and section reference remain correct.
This appears to be a long-standing edge case exposed by unusually aggressive testing, not a regression from the file-persistence refactor.
Reproduction observed
- Open a large Excalidraw Markdown drawing in two side-by-side views.
- Include a back-of-the-note embeddable linked to a section in that drawing.
- Edit a Markdown image or make alternating scene edits in the two views while saves and synchronization are occurring.
- Optionally move a view to a popout or back to the main workspace during the activity.
- Rarely, a back-of-the-note embeddable initializes as an image of the entire drawing rather than the selected section.
The issue was also observed while adding a second back-of-the-note section: the new embeddable in the other view displayed the whole drawing.
Actual behavior
- The complete drawing is rendered inside the embeddable.
- The embeddable cannot be edited in this state.
- Its stored link and section reference remain correct.
- Force save does not repair the presentation.
- Closing and reopening the Excalidraw view restores the correct section.
Expected behavior
The native Canvas-backed embeddable should display the linked Markdown section and remain editable, including when initialized during save, synchronization, or window migration.
Technical notes
RenderObsidianView resolves the link and CanvasNodeFactory.createFileNote() synchronously creates a native Canvas file node, calls setFilePath(file.path, subpath), and calls render(). A transient metadata/subpath or native Canvas-node initialization state is suspected, but has not been proven by a runtime trace.
An experimental metadata-change listener that called node.render() after the subpath became resolvable was unsuccessful: rerendering could activate the back-of-the-note editor, steal focus from the Markdown image editor, and still did not reliably repair the whole-drawing state. That experiment was fully reverted and must not be restored as the fix.
A future investigation should capture the native node child type, retained subpath, editing/active state, and metadata resolution at the first incorrect initialization before changing behavior.
Frequency and impact
Rare and observed only under aggressive concurrent editing/migration tests. Persisted drawing data and the embeddable link were not damaged; reopening the view recovered the correct rendering.
Source: zsviczian/obsidian-excalidraw-plugin