chore: prlinter crashes if it runs alongside itself #33129
Conversation
There is a race condition between multiple runs of the PR linter: it finds a review that it wants to dismiss, but if that already has been dismissed by another PR linter running in parallel the API call fails and the linter does too. Catch this specific case.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #33129 +/- ##
=======================================
Coverage 81.57% 81.57%
=======================================
Files 227 227
Lines 13793 13793
Branches 2419 2419
=======================================
Hits 11251 11251
Misses 2270 2270
Partials 272 272
Flags with carried forward coverage won't be shown. Click here to find out more.
|
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
|
This pull request has been removed from the queue for the following reason: Pull request #33129 has been dequeued, merge conditions unmatch:
You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it. If you want to requeue this pull request, you need to post a comment with the text: |
aws-cdk-automation
dismissed
their stale review
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
|
@Mergifyio requeue |
✅ The queue state of this pull request has been cleaned. It can be re-embarked automatically |
|
This pull request has been removed from the queue for the following reason: Pull request #33129 has been dequeued, merge conditions unmatch:
You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it. If you want to requeue this pull request, you need to post a comment with the text: |
aws-cdk-automation
dismissed
their stale review
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
rix0rrr
added
the
pr-linter/exempt-codecov
|
@Mergifyio requeue |
✅ The queue state of this pull request has been cleaned. It can be re-embarked automatically |
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
If we don't know the result of the CodeCov results yet, we used to ask for changes, because it prevents merging while the check might still fail in the future. The following sequence of events happens because of this: 1. PR is ready to be merged (approved, everything passes) 2. Mergify enqueues it and merges from main 3. CodeCov needs to run again 4. PR linter requests changes because CodeCov result is uncertain 5. Mergify dequeues the PR because PR linter requests changes This looks very confusing and noisy, and also will never fix itself, so the PR ends up unmerged. You can see it happening here: #33129 The better solution would probably be not to do a "Request Changes" review, but leave a comment and create a GitHub "status" on the PR to say 'success/pending/failure', and make it required. (#33136) For now, not doing anything with a 'waiting' status is a smaller delta, and the race condition posed by it is unlikely to happen given that there are much slower jobs that the merge is blocked on anyway. See also #33136. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
Comments on closed issues and PRs are hard for our team to see. |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
There is a race condition between multiple runs of the PR linter: it finds a review that it wants to dismiss, but if that already has been dismissed by another PR linter running in parallel the API call fails and the linter does too.
Catch this specific case.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license