[Bug]: Changes to snippets are immediately reverted a couple of seconds after the user stops typing

[BryanWall]

Describe the bug

When trying to edit snippets created in a previous version of massCode, changes typed immediately revert after the user stops typing

To reproduce

1. Select a snippet created in a previous version of massCode (when it was using 3 backticks for the snippet container)
2. Try typing changes to the snippet
3. After a couple of seconds the change disappears and the content reverts to the previous state

Possibly related to #696 ?

masscode-v5.5-revert.mov

App Version and Architecture

v5.5.0 arm-64

System info

OS: macOS 26.5
    CPU: (10) arm64 Apple M1 Pro
    Memory: 224.81 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh

Validations

• Follow our Code of Conduct
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion.

[BryanWall]

I noticed that new snippets created using v5.5.0 are using 3 backticks as the container format again, instead of 4 backticks. Was this an intentional change?

I've seen the issue occur a couple of times with snippets I created new in v5.5.0, but haven't figured out how to reproduce it. Is it possible that new snippets which are using the 3 backticks are still triggering the issue sometimes? Even with old snippets it doesn't happen every time. It's a bit random.

[antonreshetov]

Could you check whether the affected .md snippet and nearby snippets have duplicate contents[].id values in frontmatter?

The 3-backtick fence itself does not look like the issue in v5.5.0. The serializer now chooses a longer fence when the content contains backticks.

Example:

contents:
  - id: 1

[BryanWall]

Yes, several snippets in the same folder have the same contents block in the .md

contents:
  - id: 1
    label: Fragment 1

The id: outside the contents block is different for each one, though.

I duplicated each snippet and deleted the original to fix the duplicate id: values.

[antonreshetov]

Thanks for checking. That confirms the likely cause.

The update path currently resolves fragments by contentId globally. With duplicate contents[].id values, an edit can hit the wrong fragment and then look like a revert after sync.