Repository navigation
feat: implement issue #490 — Compliance: stub-surface-drift-pr-auto-review.yml-concurrency - #491
Conversation
…eview.yml-concurrency
|
ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
|
Warning Review limit reachedNext included review available in 53 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: Repository: petry-projects/markets/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: petry-projects/markets/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe workflow now groups selected ChangesPR auto-review concurrency
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
Dev-Lead — waiting on PR blockers (intent: review-changes)PR: #491 |
|
Note @don-petry I reviewed this PR and no code changes were needed, but it still has blocking checks or reviews (failing or cancelled checks, or changes-requested reviews), so I cannot mark it done yet. I'll re-check automatically. |
|
No description provided. |
|
Advisory bots were rate-limited; auto-approval is withheld until they recover. pr-review-sweep will re-review this PR after 2026-09-20T20:30:59Z. |
CodeAnt Nitpicks1 code suggestion1.
|
|
Fixed in |
Dev-Lead — fix-bot-comment (applied)Changes committed and pushed. |
donpetry-bot
left a comment
There was a problem hiding this comment.
Automated review — APPROVED ✓
Risk: MEDIUM
Reviewed commit: a09f1200afc6fa12460e087a8c2f7b4cfb709411
Cascade: triage → deep (triage: haiku 4.5 [sonnet 5] → deep: opus 4.8 [sonnet 5] + duck: o4-mini → audit: fable 5)
Summary
PR #491 re-syncs the pr-auto-review.yml caller stub's concurrency: block to the org canonical standard to remediate compliance drift issue #490; the added block is byte-identical to petry-projects/.github standards/workflows/pr-auto-review.yml (diff empty, confirmed). The concurrency expression is structurally correct — null-safe pull_requests indexing, unique-group fallback for PR-head/no-PR events, and cancel-in-progress scoped only to check_suite/workflow_run. The CodeAnt pull_requests[0] finding that triggered escalation is a nitpick about the centrally-owned canonical pattern (multiple PRs sharing one head commit); the stub is explicitly not repo-adjustable, so any fix belongs in the central reusable, not this drift-remediation PR. All gates pass and there is no security surface, so this is approved.
Findings
- info: concurrency group uses pull_requests[0], so if a single head commit is shared by multiple open PRs, only the first PR names the group and (with cancel-in-progress) a run relevant to the other PR(s) can be superseded. This is a genuine but low-probability edge case (uncommon for CI, which runs per-commit; and the surviving run still carries the full pull_requests list). It is CodeAnt's own nitpick about the ORG canonical pattern, not a defect introduced by this PR: the block is byte-identical to standards/workflows/pr-auto-review.yml and issue #490 mandates a verbatim re-sync. The concurrency surface is centrally owned and not repo-adjustable, so remediating it here would re-introduce drift and violate the compliance requirement — the correct venue is a PR against the central reusable/standard.
- info: Verified the boolean structure of the group expression: for check_suite/workflow_run with an associated PR it yields pr-auto-review-ready-check-pr-; for an empty pull_requests array the null-safe [0].number access falls through to the unique-per-run group; pull_request and pull_request_review always take the unique-group branch and cancel-in-progress is false for them. Behavior matches the documented intent.
- info: Description is missing 4 of 5 required sections (risk, test-plan, rollback, monitoring). Not treated as a gate failure here: this is a machine-generated (compliance-finding, machine-owned labels) verbatim standards-sync — WORKFLOW_ONLY_CHANGE and STANDARDS_SYNC_PR are true — which the standards-sync carve-out relieves from the description gate.
Reviewed by the PR-review cascade (triage: haiku 4.5 [sonnet 5] → deep: opus 4.8 [sonnet 5] + duck: o4-mini → audit: fable 5). Reply if you need a human review.
|
|
Advisory bots were rate-limited; auto-approval is withheld until they recover. pr-review-sweep will re-review this PR after 2026-09-20T20:38:59Z. |
donpetry-bot
left a comment
There was a problem hiding this comment.
Automated review — APPROVED ✓
Risk: MEDIUM
Reviewed commit: 864e960d170d480b34829bcddb17abc076ef04cf
Cascade: triage → deep (triage: haiku 4.5 [sonnet 5] → deep: opus 4.8 [sonnet 5] + duck: o4-mini → audit: fable 5)
Summary
Workflow-only standards-sync change (closes #490) adding a concurrency block to the pr-auto-review thin caller stub. The expression correctly routes pull_request/pull_request_review to per-PR cancel-in-progress groups and check_suite/workflow_run/no-PR to unique-per-run non-cancelling groups, which is precisely what avoids the pull_requests[0] indeterminacy race; logic traced and YAML validated. Only escalation signal was the missing description sections, which the trusted first-party standards-sync caller-stub carve-out neutralizes (workflow-only, first-party pinned reusable, no secret in run step, no third-party reusable, no hard-stops).
Findings
- info: Concurrency group expression is correct: pull_request and pull_request_review resolve to 'pr-auto-review-ready-check-pr-{number}' with cancel-in-progress=true, while check_suite/workflow_run and any no-PR trigger fall through to 'pr-auto-review-ready-check-unique-{run_id}' with cancel-in-progress=false. This intentionally avoids collapsing/cancelling across distinct PRs that share a commit (the pull_requests[0] indeterminacy). The 'A && B || C' idiom is safe because format() always yields a non-empty (truthy) string. pull_request and pull_request_review for the same PR intentionally share a group (latest readiness check wins).
- info: CodeAnt's 'pull_requests[0] race condition' nitpick does not apply to this diff — the added code never references github.event.*.pull_requests[0]; it uses github.event.pull_request.number (per-PR) and github.run_id (unique) instead. The nitpick appears to reference a pattern the PR deliberately avoids.
- minor: PR description is missing 4 of 5 required sections (risk, test-plan, rollback, monitoring). Non-gating here: this is a workflow-only, first-party standards-sync caller-stub PR (STANDARDS_SYNC_PR=true, WORKFLOW_ONLY_CHANGE=true, SECRET_IN_RUN_STEP=false, THIRD_PARTY_REUSABLE_ADDED=false, no deterministic hard-stops), so the carve-out waives the terse-description gate.
Reviewed by the PR-review cascade (triage: haiku 4.5 [sonnet 5] → deep: opus 4.8 [sonnet 5] + duck: o4-mini → audit: fable 5). Reply if you need a human review.



Closes #490
Implemented by dev-lead agent. Please review.
Summary by CodeRabbit