fix(sync): ensure sync-branch worktree exists on fresh clone#1349
Merged
steveyegge merged 1 commit intosteveyegge:mainfrom Jan 27, 2026
Merged
Conversation
jdelfino
force-pushed
the
fix/ensure-worktree-on-fresh-clone
branch
from
c59f213 to
8867da4
Compare
jdelfino
force-pushed
the
fix/ensure-worktree-on-fresh-clone
branch
from
8867da4 to
f191402
Compare
On fresh clone, findJSONLPath() would silently fall back to main's stale JSONL because the sync-branch worktree didn't exist yet. The worktree was only created on first daemon sync (write operation), but import operations (reads) would use the stale data. This caused sync failures when containers were rebuilt - issues accumulated on beads-sync branch were not imported after rebuild because main's stale JSONL was used instead. The data still existed on beads-sync, but the local database was populated with outdated state. The fix: 1. Add EnsureWorktree() in internal/syncbranch/worktree.go - creates the sync-branch worktree if configured but doesn't exist 2. Call EnsureWorktree() from ensureStoreActive() in direct_mode.go - guarantees worktree exists before any JSONL operations 3. Add debug logging when getWorktreeJSONLPath() falls back (now rare) The EnsureWorktree() function is idempotent - safe to call multiple times. The underlying CreateBeadsWorktree also performs health checks and auto-repairs unhealthy worktrees. Includes comprehensive tests for: - Worktree not created when sync-branch not configured - Worktree created when sync-branch configured via env - Worktree created when remote branch exists - Idempotent behavior on repeated calls - Fresh clone scenario end-to-end test Co-Authored-By: Claude Opus 4.5 <[email protected]>
jdelfino
force-pushed
the
fix/ensure-worktree-on-fresh-clone
branch
from
f191402 to
6bd28a5
Compare
jdelfino
changed the title
steveyegge
approved these changes
Jan 27, 2026
Owner
steveyegge
left a comment
steveyegge
left a comment
There was a problem hiding this comment.
Well-designed fix for the fresh clone scenario. The EnsureWorktree function is properly idempotent and handles edge cases (not in git repo, sync-branch not configured) gracefully. Good test coverage including an end-to-end fresh clone scenario test. LGTM.
🤖 Reviewed by PR Sheriff (beads/crew/emma)
groblegark
pushed a commit
to groblegark/beads
that referenced
this pull request
Jan 31, 2026
On fresh clone, findJSONLPath() would silently fall back to main's stale JSONL because the sync-branch worktree didn't exist yet. The worktree was only created on first daemon sync (write operation), but import operations (reads) would use the stale data. This caused sync failures when containers were rebuilt - issues accumulated on beads-sync branch were not imported after rebuild because main's stale JSONL was used instead. The data still existed on beads-sync, but the local database was populated with outdated state. The fix: 1. Add EnsureWorktree() in internal/syncbranch/worktree.go - creates the sync-branch worktree if configured but doesn't exist 2. Call EnsureWorktree() from ensureStoreActive() in direct_mode.go - guarantees worktree exists before any JSONL operations 3. Add debug logging when getWorktreeJSONLPath() falls back (now rare) The EnsureWorktree() function is idempotent - safe to call multiple times. The underlying CreateBeadsWorktree also performs health checks and auto-repairs unhealthy worktrees. Includes comprehensive tests for: - Worktree not created when sync-branch not configured - Worktree created when sync-branch configured via env - Worktree created when remote branch exists - Idempotent behavior on repeated calls - Fresh clone scenario end-to-end test Co-authored-by: Claude Opus 4.5 <[email protected]>
groblegark
pushed a commit
to groblegark/beads
that referenced
this pull request
Jan 31, 2026
On fresh clone, findJSONLPath() would silently fall back to main's stale JSONL because the sync-branch worktree didn't exist yet. The worktree was only created on first daemon sync (write operation), but import operations (reads) would use the stale data. This caused sync failures when containers were rebuilt - issues accumulated on beads-sync branch were not imported after rebuild because main's stale JSONL was used instead. The data still existed on beads-sync, but the local database was populated with outdated state. The fix: 1. Add EnsureWorktree() in internal/syncbranch/worktree.go - creates the sync-branch worktree if configured but doesn't exist 2. Call EnsureWorktree() from ensureStoreActive() in direct_mode.go - guarantees worktree exists before any JSONL operations 3. Add debug logging when getWorktreeJSONLPath() falls back (now rare) The EnsureWorktree() function is idempotent - safe to call multiple times. The underlying CreateBeadsWorktree also performs health checks and auto-repairs unhealthy worktrees. Includes comprehensive tests for: - Worktree not created when sync-branch not configured - Worktree created when sync-branch configured via env - Worktree created when remote branch exists - Idempotent behavior on repeated calls - Fresh clone scenario end-to-end test Co-authored-by: Claude Opus 4.5 <[email protected]>
groblegark
pushed a commit
to groblegark/beads
that referenced
this pull request
Jan 31, 2026
On fresh clone, findJSONLPath() would silently fall back to main's stale JSONL because the sync-branch worktree didn't exist yet. The worktree was only created on first daemon sync (write operation), but import operations (reads) would use the stale data. This caused sync failures when containers were rebuilt - issues accumulated on beads-sync branch were not imported after rebuild because main's stale JSONL was used instead. The data still existed on beads-sync, but the local database was populated with outdated state. The fix: 1. Add EnsureWorktree() in internal/syncbranch/worktree.go - creates the sync-branch worktree if configured but doesn't exist 2. Call EnsureWorktree() from ensureStoreActive() in direct_mode.go - guarantees worktree exists before any JSONL operations 3. Add debug logging when getWorktreeJSONLPath() falls back (now rare) The EnsureWorktree() function is idempotent - safe to call multiple times. The underlying CreateBeadsWorktree also performs health checks and auto-repairs unhealthy worktrees. Includes comprehensive tests for: - Worktree not created when sync-branch not configured - Worktree created when sync-branch configured via env - Worktree created when remote branch exists - Idempotent behavior on repeated calls - Fresh clone scenario end-to-end test Co-authored-by: Claude Opus 4.5 <[email protected]>
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
2 participants
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.
Summary
On fresh clone,
findJSONLPath()would silently fall back to main's stale JSONL because the sync-branch worktree didn't exist yet. The worktree was only created on first daemon sync (write operation), but import operations (reads) would use the stale data.This caused sync failures when containers were rebuilt - issues accumulated on beads-sync branch were not imported after rebuild because main's stale JSONL was used instead. The data still existed on beads-sync, but the local database was populated with outdated state.
The Fix
EnsureWorktree()ininternal/syncbranch/worktree.go- creates the sync-branch worktree if configured but doesn't existEnsureWorktree()fromensureStoreActive()indirect_mode.go- guarantees worktree exists before any JSONL operationsgetWorktreeJSONLPath()falls back (should now be rare)The
EnsureWorktree()function is idempotent - safe to call multiple times. The underlyingCreateBeadsWorktreealso performs health checks and auto-repairs unhealthy worktrees.Root Cause Analysis
The issue was in the read path:
findJSONLPath()callsgetWorktreeJSONLPath()""causing fallback to main's JSONLbd sync --import-onlywhich uses the stale pathThe write path worked correctly - daemon creates worktree before committing. But reads happened before writes on fresh clone.
Tests
Test plan
go test ./internal/syncbranch/... -run TestEnsureWorktreego test ./internal/syncbranch/... -run TestFreshCloneScenariogo test ./...bdcommand🤖 Generated with Claude Code