Conversation
…epo_root() register_project_dir and register_bridge_repo called the raw, cwd-derived repo_root() instead of worktree_repo_root(), so a process dispatched into a linked worktree (e.g. an agent running from .worktrees/task/40) wrote its own worktree path into the shared, daemon-wide project_dirs and bridge_repos registries. The next discovery tick then built a new item's worktree relative to that poisoned path, nesting one worktree inside another (item #91). project_link_path and resolve_repo_key were audited and left unchanged: project_link_path only produces a redundant per-worktree link file since .agentflare/ is gitignored and resolve_repo_key() reconnects worktrees to the same project via the git remote regardless; resolve_repo_key only falls back to the raw repo_root() when there is no git remote, which never happens for a GitHub-hosted repo. Added a regression test exercising register_project_dir/register_bridge_repo through worktree_repo_root_override, asserting the registries end up with the redirected root rather than the raw one. Split the project-resolution tests out of item_tests.rs into their own submodule to keep it under the repo's LOC gate. Agentflare-Agent: claude-code Agentflare-Branch: task/94 Agentflare-Item: 94
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 44 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
Comment |
getappz
changed the title
…ries (#463) (#478) Queue::fail now reports whether a failure was terminal (retries exhausted) vs a requeue. WorkerPool gains a terminal_failure_hook fired from run_in_process on that terminal case; the daemon wires it to dashboard::orphan_reconcile::handle_terminal_job_failure, which swaps the item off dispatched onto needs-manual-dispatch (or ready-for-work as a fallback) -- the clean-failure counterpart to reconcile_orphaned_jobs, which only ever covered a job whose process crashed mid-flight. Previously an item whose dispatched job failed for an ordinary reason (no billing balance, transient network error) stayed labeled dispatched forever, invisible to every future discovery tick. Agentflare-Agent: claude-code Agentflare-Branch: task/463-failed-jobs-retries-exhausted-leave-item Agentflare-Item: 463
1 participant
Working tree is clean and the commit is in place. Only 1 failure this run (
mcp_prompts::tests::optimize_review_returns_full_skill_body— the same pre-existing, unrelated failure noted before;dashboard::serverdidn't reappear, confirming it's a timing flake, not caused by this change). 1249/1250 passed, no failures inmcp_server::.Summary
Fixed item #94:
register_project_dirandregister_bridge_repoinsrc/mcp_server.rsnow callself.worktree_repo_root()instead of the raw, cwd-derivedSelf::repo_root(), so a process dispatched into a linked worktree (e.g..worktrees/task/40) no longer poisons the sharedproject_dirs/bridge_reposregistries with its own worktree path — the root cause of item #91's nested-worktree bug.project_link_pathandresolve_repo_keywere audited per the item's guidance and left unchanged (documented why in the commit).resolve_project_registers_the_worktree_redirected_root_not_the_raw_repo_root) exercising the fix viaworktree_repo_root_override, avoiding the real-cdrace that caused the earlier "Reopened" regression inresolve_project_relinks_to_existing_project_when_link_file_is_deleted.item_tests.rshad grown past the repo's 1500-line LOC gate; split the project-resolution tests into a newproject_resolution_tests.rssubmodule to pass the pre-commit hook cleanly (no--no-verifyused).9a6acce; full suite is green aside from one pre-existing, unrelated flaky failure inmcp_prompts.