Repository navigation
fix(checkpoints): a revert never applies one checkout's snapshots to another - #912
Merged
Merged
Conversation
…older is behind a symlink Starting a thread in another thread's checkout failed with "is no longer a worktree of this project" whenever the data folder sat behind a symlink (macOS /var for /private/var): git lists a worktree by its real path, and the thread had recorded it through the symlink. The setup now compares the two as the disk resolves them. Found in a live run with a real agent.
…another A thread can move to another checkout between turns (the user's own switch, an agent's move, a session that settled somewhere else), and every checkout of a repository shares its checkpoint refs. A revert to a turn from before the move then applied snapshots of the folder the thread had left to the folder it was in, and for a thread alone in its worktree restored the other folder's whole tree over it. - Every snapshot now records the checkout it was taken in, as a `threadlines-checkout` trailer: `.` for the main checkout, else `worktrees/<name>`, so a renamed or symlinked folder is still the same checkout. - `checkpointCheckouts` answers, per ref, here, elsewhere or unknown. - A revert is refused when a turn it would undo has a completion or starting snapshot from another checkout. When only its target is from another checkout, it restores from the first undone turn's own starting snapshot, which is this folder right before that turn. - The move an agent made, on the thread's record, now only stands in for snapshots that don't say where they were taken.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two fixes that follow #911 (a thread working in a checkout another thread already has).
A revert could apply one checkout's snapshots to another
A thread can move to another checkout between turns: the user's own switch, an agent's move, a session that settled somewhere else. Every checkout of a repository shares its checkpoint refs, so a revert to a turn from before the move applied snapshots of the folder the thread had left to the folder it was in. For a thread alone in its worktree it restored the other folder's whole tree over it.
threadlines-checkouttrailer besidethreadlines-head:.for the main checkout, elseworktrees/<name>(git's own name for it, so a renamed or symlinked folder is still the same checkout).checkpointCheckoutson the VCS driver andCheckpointStoreanswers, per ref:here,elsewhereorunknown(a snapshot from before this, or a ref that is gone).CheckpointRevert.resolveContextrefuses a revert when a turn it would undo has a completion or starting snapshot from another checkout. When only the target is from another checkout (a revert to the turn the thread moved after), it restores from the first undone turn's own starting snapshot, which is this folder right before that turn.thread.checkout.movedactivity from feat(threads): an agent can put a thread in a checkout another thread already has #911 now only stands in for snapshots that don't say where they were taken.Capture reads the checkout id alongside the head commit, so it adds no wait to a turn.
Starting in another thread's checkout failed behind a symlink
A live run of #911 with a real agent failed with "is no longer a worktree of this project" because the data folder sat behind a symlink (macOS
/varfor/private/var): git lists a worktree by its real path and the thread had recorded it through the symlink. The setup now compares the two as the disk resolves them.Checked
vp fmt,vp lint,vp run typecheck,vp run test(full suite)CheckpointStore.test.ts), the revert rules (CheckpointRevert.test.ts), the symlink case (ThreadBootstrap.test.ts)Not checked