chore(master): release 4.2.0 - #405
Conversation
|
Warning Review limit reachedNext included review available in 58 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
00e0e25 to
cb2bbad
Compare
Review triageSurfaced by CI: all 6 check runs green ( Review: none ran. CodeRabbit's commit status reads Findings: none to dispose of. Nothing was reviewed, so nothing was said. Content: release-please restating two commits already on Caveat on that reassurance, stated because it is load-bearing here: #401's own review arrived after it merged, and all five findings were valid — corrected in #406. So "each reviewed when it merged" is weaker for Recommendation: merge on the human's call, with the unreviewed status on the record. Note that mlorentedev/dotfiles exempts release-please PRs from its attestation gate on exactly this rationale; hive's registry deliberately does not carry that exemption (#407 explains why — |
#407) Closes #403. ## The problem ``` $ dotf pr triage-queue pr triage-queue: read reviewer registry: open harness/review-attestation.json: no such file or directory $ echo $? 1 ``` That command exits non-zero for **two different reasons** — work is pending, or the question could not be answered — deliberately, so an unanswerable queue is never mistaken for a clear one. Here it was always the second. The consequence: hive could produce **no queue-clear evidence for any PR, ever**, so every PR closed with the Definition of Done's evidence item skipped rather than met. ## The non-obvious part: which marker identifies a review This is not a copy of the dotfiles registry, and the reason is worth reading before reviewing the file. CodeRabbit files **proper reviews through the reviews API** on this repo. Measured on #401: a 5-finding review reading `**Actionable comments posted: 5**`, sitting in `reviews[]`. But the queue reads `gh pr list --json comments`, which returns issue comments **only** and never `reviews[]`. Matching the review's own text would have left the queue permanently empty on a repository that is actively being reviewed — the exact false clear the mechanism exists to prevent. So the registered marker is the **walkthrough comment** CodeRabbit posts alongside every review, which is comment-shaped. Verified present on both PRs open at the time of writing: | PR | Walkthrough marker | Rate-limit marker | What it was | |---|---|---|---| | #401 | ✅ | — | a real 5-finding review | | #406 | ✅ | ✅ | a decline | **The limitation this leaves is stated in the file, not left to be rediscovered:** the walkthrough is *edited* rather than reposted on re-review, and `createdAt` does not move on an edit — so a second review after a push may not re-open the queue for a PR already triaged once. The queue is a floor, not a ceiling. Closing that needs a consumer that reads `reviews[]`, which is a change to the dotfiles CLI, not to this file. ## `advisory: true`, measured here rather than inherited On **#405 and #406**, CodeRabbit was rate limited, posted *"Review limit reached"*, and its **commit status read `success`**. A green check that means no review ran is precisely the failure this whole mechanism exists to catch. Advisory means its *decline* does not refuse the change — a quota is a billing state of a third party, not a property of the diff — while its *review* still attests. Note what the two settings do together, and it is intended: the decline notice also carries the walkthrough marker, so **a rate-limited PR reads as output awaiting disposition rather than as a clear queue.** That is the honest answer. ## Deliberately absent The `escape` and `exempt` blocks dotfiles carries. Those are read by its review-attestation **CI gate**, which hive does not run — `prtriage` reads `reviewers` and `triage.marker` and nothing else. A registry declaring policy no consumer here enforces is drift with extra steps. The practical consequence: release-please PRs are not exempted and will queue for a one-line disposition. ## Verified end to end ``` $ dotf pr triage-queue 1 pull request(s) awaiting a disposition: #405 chore(master): release 4.1.1 coderabbitai reviewed, never triaged, 2026-08-24 20:47 ``` Both directions confirmed: **#406 correctly omitted** (it carries a `## Review triage` comment) and **#405 correctly surfaced** (it does not). The queue found a real open PR I did not know existed. `AGENTS.md` gains two bullets in the PR workflow section: how to run the queue and where to record the disposition, and the warning that CodeRabbit's green status can mean it never reviewed.
mlorentedev
changed the title
b3b829e to
aba734d
Compare
|
@coderabbitai review |
|
7cfd077 to
70b5048
Compare
Review triageAmending the disposition above: it described 4.1.1 and this PR is now 4.2.0 (head CI: green on the new head. Review: still none. No new CodeRabbit output arrived after the re-cut; its only walkthrough comment predates the first disposition (02:47Z vs 03:15Z). This PR remains unreviewed. Worth naming, because this PR is the live example of it. Findings: none to dispose of. Content is release-please restating commits already on Recommendation: unchanged — merge on the human's call with the unreviewed status on the record. |
Lesson 096, from the #403 / #407 work. It merged before this was written; this carries the part worth keeping. ## The finding `dotf pr triage-queue` calls `gh pr list --json comments`. GitHub exposes a PR's discussion through **three separate surfaces** — issue comments, the reviews API (`reviews[]`), and inline review comments — and that call returns **only the first**. On this repo CodeRabbit files *proper* reviews. #401's five findings live in `reviews[]` as `**Actionable comments posted: 5**`; `comments` held only the walkthrough. So registering the review's own text as the marker would have produced a queue that was **permanently, silently empty on a repository that was being reviewed the whole time**. The dotfiles registry does not hit this because its second reviewer, PR-Agent, publishes *through* the comments API — which is why its marker does not transfer, and why "port the config" was the wrong mental model for #403. ## Why it is worth a lesson rather than a commit message The direction of failure. A wrong marker does not error — it returns *"no reviewer output yet"*, which is also what a genuinely quiet PR looks like. Same family as [087](docs/lessons/lesson-087-a-green-review-check-can-mean-did-not-review.md) and [094](docs/lessons/lesson-094-a-verification-command-that-selects-zero-tests.md): **a check that cannot see its subject reports the subject is fine.** Two rules fall out: 1. When porting a config between repos, verify the **observable** it keys on against live data in the destination. One `gh api repos/…/pulls/N/reviews` versus `…/issues/N/comments` settles it in ten seconds; reading the source registry for an hour does not. 2. Prove a matcher in **both** directions. This one was confirmed by watching the queue correctly omit a triaged PR *and* correctly surface an untriaged one it found on its own — #405, a real open release PR nobody had looked at, invisible until the registry existed. Docs only. All wikilinks verified against the working tree.
e188098 to
9ab14ba
Compare
|
🤖 Created releases: 🌻 |
1 participant
🤖 I have created a release beep boop
4.2.0 (2026-08-25)
Features
Bug Fixes
Documentation
This PR was generated with Release Please. See documentation.