Checkout and bookmark switch race a concurrent snapshot, which then wins issue #36 closed: completed andymccall opened this 1 month ago · 0 comments

Found on metalgear (feedback issue #26), 2026-09-29 21:53. oxy bookmark switch logo-25 (op 4fea011f) rewrote the working copy while an oxy status, most likely the VS Code extension reacting to the files being written, snapshotted it. The status had read the head before the switch recorded its operation, so its working-copy change was based on the old three-head state and recorded the half-written disk as edits: 58 tree ops and 240 edits. record_op then merged the two views (op 015101d5, 'merged with a concurrent operation'). merge_views lets this process's workspace value win, so the stale snapshot replaced the switch's working copy. Status then presented the switch's rewrite as the user's changes, the switch back was refused, and discard . found nothing to discard.

Cause: only snapshot takes the workspace lock (lock_snapshot). Checkout, bookmark switch (and --carry), pull's checkout, undo, discard and commit read the head, write files and record the view without it.

Fix: every operation that writes the working copy or replaces the workspace's working-copy change holds the workspace lock from reading the head until its operation is recorded. merge_views must also never let a working-copy change based on a replaced one win: when both sides changed a workspace, the operation that did not start from the current working copy loses, and a snapshot redoes itself. Test: a snapshot concurrent with a checkout, in two threads, never records the checkout's writes as edits.