Skip to content

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

Closed

Description

@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

Activity

  1. BryanWall commented on May 13, 2026

    @BryanWall
    Author

    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.

  2. antonreshetov commented on May 14, 2026

    @antonreshetov
    Member

    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
  3. BryanWall commented on May 14, 2026

    @BryanWall
    Author

    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.

  4. antonreshetov commented on May 16, 2026

    @antonreshetov
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions