feat: worst-wins reconciliation for shared-token review types
CI / test (pull_request) Successful in 13s
CI / review (gpt-4.1, gpt, GPT_REVIEW_TOKEN) (pull_request) Successful in 24s
CI / review (gpt-5, security, SECURITY_REVIEW.md, SONNET_REVIEW_TOKEN) (pull_request) Successful in 1m9s
CI / review (gpt-5, sonnet, SONNET_REVIEW_TOKEN) (pull_request) Successful in 1m18s

When multiple review types share a Gitea bot account, Gitea uses the
latest review to determine the user's approval state. This creates a
race: if security finds issues but code-quality finishes last with
APPROVE, the PR appears approved.

Now before posting, each job checks if any sibling review from the same
user has REQUEST_CHANGES. If so and we would post APPROVE, we downgrade
to COMMENT instead — the review is still visible but won't override
the blocking state.

Documented in README under "Shared Token: Worst-Wins."
This commit is contained in:
Rodin
2026-05-01 21:10:39 -07:00
parent 6a3c813279
commit 687005d982
2 changed files with 29 additions and 0 deletions
+21
View File
@@ -226,6 +226,26 @@ func main() {
return
}
// Worst-wins: if we're about to APPROVE but a sibling review from the same
// user already has REQUEST_CHANGES, post as REQUEST_CHANGES too so we don't
// override the blocking state.
if event == "APPROVED" && *reviewerName != "" {
existing, err := giteaClient.ListReviews(ctx, owner, repoName, prNumber)
if err == nil {
for _, r := range existing {
if !r.Stale && r.State == "REQUEST_CHANGES" {
// Check it's from the same user (same token) but a different role
sentinelCheck := fmt.Sprintf("<!-- review-bot:%s -->", *reviewerName)
if !strings.Contains(r.Body, sentinelCheck) {
log.Printf("Sibling review %d has REQUEST_CHANGES; escalating to REQUEST_CHANGES", r.ID)
event = "REQUEST_CHANGES"
break
}
}
}
}
}
log.Printf("Posting review (event=%s)...", event)
posted, err := giteaClient.PostReview(ctx, owner, repoName, prNumber, event, reviewBody)
if err != nil {
@@ -249,6 +269,7 @@ func main() {
}
}
}
}
}
}