Concurrent Editing and Data Loss

How concurrent edits combine, the one case where a change can be dropped, and how to avoid it.
View as Markdown

Several people can edit the same page at the same time in Knapsack. Most of the time their changes combine without anyone having to think about it. In one specific situation, one person’s change can be dropped without a warning.

This page explains how concurrent editing works, where the gap is, and what to do about it.

How concurrent editing works

Knapsack does not lock a page while someone edits it. Two people on the same branch can open the same page and start typing.

When you save, Knapsack does not replace the whole page with your copy. It records your change as a specific instruction — “change the text in this block” — and applies that instruction to the page’s current state. Everyone’s saves are recorded the same way and applied in the order they arrive.

Because each save describes only what you changed, edits to different parts of a page combine on their own. If you rewrite one block while a colleague rewrites a different block, both changes survive and neither of you is asked to resolve a conflict.

Knapsack does not offer live co-editing. You will not see a colleague’s cursor or watch their text appear as they type. Their changes become visible to you when you reload the page or open it again later.

The one case where a change can be dropped

The problem arises when one person changes a block’s content while another changes the page’s structure — moving, reordering, or removing that same block.

A content edit is an instruction about a particular block. If that block has moved or changed shape before the instruction arrives, Knapsack can no longer apply it. When that happens, it discards the instruction and records the problem on the server. The author who made the edit sees no error.

Here is the sequence:

  1. You edit the text inside a block.
  2. A colleague working in the same section drags that block to a new position, or restructures the content around it.
  3. Their save lands first. The page’s structure is now different from the one your edit was written against.
  4. Your save lands next. It refers to a block that has moved, so Knapsack cannot apply it and drops it.
  5. Your save appears to succeed. No error appears. Your edit is gone.

What matters is the order the saves arrive, not the order in which you each started editing. You can begin first and still lose the change.

Nobody is told this happened. The author who lost the edit usually discovers it much later, when they return to the page and the change is simply not there.

Two people editing different blocks are not affected. The risk is specific to a content edit colliding with a structural change to that same block.

Edits on different branches never collide. Concurrent editing applies to one page on one branch.

Why Knapsack works this way

Recording each save as a small instruction is what makes saves fast and keeps them from interrupting you. It is also what lets most concurrent edits combine silently, which is the common case and the reason authors rarely think about concurrency at all.

The trade-off is that an instruction can become impossible to apply if the structure it referred to has changed. Knapsack does not solve this by locking pages or by pausing to ask you to resolve a merge conflict. Both approaches would slow down the ordinary case to guard against a rare one.

Knapsack does not currently offer conflict resolution, so coordinating with your team is the real protection today.

How to reduce the risk

Look for other people before you start. When you open a page someone else is already editing, Knapsack shows a banner on the editing surface. Treat it as a signal to coordinate rather than an obstacle.

Keep structural changes separate from content changes. Reordering, moving, or deleting blocks is the action that puts other people’s edits at risk. Do that work when you know nobody else is in the page.

Announce restructuring. Tell your team before you reorganize a page or section that others are actively writing in. A message costs less than re-typing lost work.

Use separate branches for large reorganizations. A branch of your own removes the collision entirely, because edits on different branches never interact.

Reload before you restructure. Reloading shows you the current state of the page, including saves that landed while you were reading it.

If content seems to be missing

Work through these in order.

  1. Reload the page. The most common explanation is not data loss. It is that you are looking at an older copy of the page, and your colleague’s version is the current one.
  2. Confirm you are on the right branch. A change made on one branch does not appear on another. Check the branch selector before concluding anything is lost.
  3. Check the page’s publish history. The edit bar shows when the page was last published, and its menu lists who published and when. If someone published after you made your change, their version is what you are now looking at.
  4. Re-enter the change. If a save was dropped, Knapsack cannot recover it. The edit was never stored, so there is no version to restore and no undo to apply.
  5. Contact support if content is missing in a way this page does not explain, or if it keeps happening. A pattern is worth investigating.

Publish history records publishes, not individual saves. On a branch that has not been published yet, it will not show a colleague’s recent saves. Reloading the page is the reliable way to see the current state of a draft.