fix(retention): fail closed on stale empty workspace after the closed twin - #191
Conversation
… twin The closed-twin fix (PR #105) pinned the canonical retention workspace to the git main worktree and proved its freshness, but the canonical workspace resolution still came from the first 'git worktree list --porcelain' entry — only conventionally the main worktree. A detached main worktree leaves the twin holding refs/heads/main; the twin heads the porcelain list and the gate would inspect the twin's empty state roots. Resolve the canonical workspace by git-dir ownership instead: the entry whose git-dir equals the repository's common git dir, never a linked worktree, never whichever worktree heads the list. The check script also still had a hollow-pass path: an aligned canonical workspace with no client records and no failures green-passed when the automation file was missing. The Friday loop is required before the first client is active, so a missing guard must fail loudly even at zero clients. Pin the canonical workspace to the git-dir owner and fail closed on a missing automation file. The regression suite now covers the stale+empty workspace under both conditions (with and without the automation file), the closed-twin git-dir ownership, and the no-client pass when the automation is in place. Co-authored-by: lane1-worker <noreply@commandcode.ai>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
Warning Review limit reached
Next review available in: 40 minutes Limit details: You’ve used the included review currently available. 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 within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (5)
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login. Comment |
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
2 participants
The closed-twin fix (PR #105) pinned the canonical retention workspace to the git main worktree and proved its freshness, but two follow-up contracts were still open on main.
canonicalMainWorktreeresolved the canonical workspace from the firstgit worktree list --porcelainentry — only conventionally the main worktree. A detached main worktree leaves the twin holdingrefs/heads/main; the twin heads the porcelain list and the gate would inspect the twin's empty state roots. Resolve the canonical workspace by git-dir ownership instead: the entry whose git-dir equals the repository's common git dir, never a linked worktree, never whichever worktree heads the list.The check script still had a hollow-pass path: an aligned canonical workspace with no client records and no failures green-passed when the automation file was missing. The Friday loop is required before the first client is active, so a missing guard must fail loudly even at zero clients.
Pin the canonical workspace to the git-dir owner and fail closed on a missing automation file. The regression suite now covers the stale+empty workspace under both conditions (with and without the automation file), the closed-twin git-dir ownership, and the no-client pass when the automation is in place.
Re-verification:
node scripts/test-retention-automation.mjspasses the full suite.