Back-of-note embeddable can initialize as the full drawing during concurrent updates

Author: zsviczianCreated Sep 13, 2026Updated Sep 13, 2026
Labelsbug

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

  1. Open a large Excalidraw Markdown drawing in two side-by-side views.
  2. Include a back-of-the-note embeddable linked to a section in that drawing.
  3. Edit a Markdown image or make alternating scene edits in the two views while saves and synchronization are occurring.
  4. Optionally move a view to a popout or back to the main workspace during the activity.
  5. 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