fix: worktree stale-registration bug + item-pipeline metadata panic - #550
Conversation
…anch create_worktree() only checked worktree_already_checked_out(), which requires the on-disk directory to still exist. If a worktree dir was removed out-of-band (crash, manual cleanup) while git's own .git/worktrees/<slug>/ registration survived, the branch stayed git-internally tied to the missing path, so git worktree add refused to reuse it, and the failed add itself regenerated a fresh broken registration -- every dispatch attempt reproduced the same failure forever (confirmed live on item #331: three consecutive dispatches, three identical failures). Prune before reusing an existing branch so a stale registration never survives to block it. Also surface the real worktree_error in execute_work_impl instead of a hardcoded generic message, since the underlying git failure was already captured but silently dropped. Agentflare-Agent: claude-code_2-1-234_agent Agentflare-Branch: fix/511-worktree-prune-stale-registration
…tem metadata persist_run_id blindly cloned the item's existing metadata Value and assigned a key into it via IndexMut. When metadata was corrupted into a double-JSON-encoded string (confirmed live on item #331 -- the literal string "{\"size\": \"M\"}" stored instead of the object {"size": "M"}), parsing it produced Value::String(...), and IndexMut panics assigning a key into anything that isn't already an object -- crashing the whole job with "cannot access key workflow_run_id in JSON string" on every single dispatch attempt. Coerce to an empty object when the existing value isn't already one, instead of trusting its shape. Regression test verified red (exact panic reproduced) without the fix, green with it. Agentflare-Agent: claude-code_2-1-234_agent Agentflare-Branch: fix/511-worktree-prune-stale-registration
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Included review availability: 0 reviews are currently available. Based on recent review activity, included reviews refill at 1 per hour. 📝 WalkthroughWalkthroughThe PR prunes stale Git worktree registrations before branch checkout, includes detailed worktree errors in failure messages, and normalizes non-object metadata before persisting workflow run IDs. Regression tests cover worktree recreation and metadata persistence. ChangesWorktree and metadata recovery
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to The PR fixes two localized failure modes with regression coverage, and no actionable merge-blocking risk remains after normal checks and review. Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
…une-stale-registration Agentflare-Agent: claude-code_2-1-234_agent Agentflare-Branch: fix/511-worktree-prune-stale-registration
…554) Fix #550 landed the claim["worktree_error"] handling in execute_work_impl but shipped without a regression test at that call site. Add one that drives execute_work_impl end-to-end through a real claim against a non-git repo_root and asserts the posted comment carries the server's detail instead of falling back to the generic "(bad git state?)" message. Split into a sibling file (work.rs is frozen at the LOC gate's limit). Agentflare-Agent: claude-code Agentflare-Branch: task/154-execute-work-impl-worktree-error-test Agentflare-Item: 154 Co-authored-by: shiva <shiva@gosysinfo.tech>
… returns None item::get failing to read the item back immediately after its own claim acquired it left worktree_error unset, so execute_work_impl (already fixed in #550/#554 to display worktree_error) had nothing to show and fell back to the generic "bad git state?" guess for this one case. resolve_target_branch is infallible, so this arm is only reachable via that item::get failure. Agentflare-Agent: claude-code Agentflare-Branch: task/153-execute-work-impl-discards-claim-s-workt Agentflare-Item: 153
… returns None (#586) item::get failing to read the item back immediately after its own claim acquired it left worktree_error unset, so execute_work_impl (already fixed in #550/#554 to display worktree_error) had nothing to show and fell back to the generic "bad git state?" guess for this one case. resolve_target_branch is infallible, so this arm is only reachable via that item::get failure. Agentflare-Agent: claude-code Agentflare-Branch: task/153-execute-work-impl-discards-claim-s-workt Agentflare-Item: 153 Co-authored-by: shiva <shiva@gosysinfo.tech>
Summary
execute_work_implsurfaces the realworktree_errorinstead of a hardcoded generic message.cannot access key "workflow_run_id" in JSON string) whenever an item'smetadatafield was a non-object JSON value (confirmed live on item feat: migrate artifact storage onto agentflare-store documents+blobs + vent: origin routing, throttle, batched filing, judge-prompt hook #331 — a double-JSON-encoded string). Now coerces to an empty object defensively instead of trusting the caller-supplied value's shape.Both root-caused and reproduced live against item #331 today, which hit both bugs back-to-back across ~10 dispatch attempts.
Test plan
cargo test -p flare-git-core— 190 passedcargo test --bin agentflare worktree— 17 passedcargo test --bin agentflare work_item_pipeline— 53 passed, 2 pre-existing unrelated ignorescargo fmt --checkcleancargo clippy --all-targets -- -A unsafe_code -A clippy::pedanticcleanSummary by CodeRabbit
Bug Fixes
Tests