[WRONG BRANCH] Promote dev to preview: alert-precision record - #1975
Conversation
…e's fault My second explanation was also wrong. Dev is not scanned on push - its last analysis is from 8/15, default setup runs weekly, and 0be660a is not an ancestor of that commit, so the code was never in a dev scan. Dev's 84 alerts are stale rather than current, which is the opposite of what I said they showed. The real answer: github-advanced-security posted the finding as an inline review comment on #1959 at 02:38:08Z, and #1963 promoted at 02:55:04Z. It sat in the review thread of a promotion PR for seventeen minutes - while I was editing that same PR's description. Not a coverage gap. I did not read the review comments on a PR I was actively rewriting. Three explanations for one mistake. The first two blamed infrastructure; the third is true and the least comfortable, which is roughly how that tends to go.
The alert still reads open, and it would be easy to call that a formality. It is not: fixed and closed are different claims. The code is fixed and promoted - 59d57a9 is an ancestor of all three branches, the trees are byte-identical, and a reviewer fuzzed 400,000 adversarial strings against the replaced regex with zero differences. Queried against the branch that contains the fix, alert 87 returns zero. The main ref simply has not rescanned since. Also recording what I did not fix. Thirty other instances of the same pattern remain in src/, with open alerts on at least six. All predate this campaign, so the scoped claim holds - but they take the same baseUrl input my fix comment argues about, and leaving them unmentioned would be the convenient framing rather than the honest one.
docs(devlog): final Wave 5 campaign record, including its own errors
docs(devlog): separate fixed-in-code from closed-by-scan for CodeQL #87
|
Warning Review limit reached
Next review available in: 6 seconds Limit details: You’ve used all 10 included reviews currently available under your plan. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
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 |
github-actions
Bot
added
the
documentation
|
✅ Deterministic PR hygiene checks passed. |
github-actions
Bot
changed the title
⏳ DRAFT
What to do
Its title has been prefixed with |
…w-w5d Promote dev to preview: alert-precision record
1 participant
Devlog-only. Records that CodeQL #87 is fixed in code and verified by scan on the branch containing the fix, while the main ref alert has not yet rescanned - fixed and closed being different claims. Also records the 30 pre-existing instances of the same pattern that this campaign did not fix.