With shared tokens and parallel CI jobs, a deadlock can occur:
sonnet → REQUEST_CHANGES, security → escalates to REQUEST_CHANGES
Dev fixes, pushes
sonnet wants APPROVED but sees security REQUEST_CHANGES → re-escalates
security wants APPROVED but sees sonnet REQUEST_CHANGES → re-escalates
Mitigated by the stale flag (reviews from old commits are skipped), but within the same CI run with parallel jobs, the race is theoretically possible.
Best fix: separate tokens per role (see sister issue). Alternative: don't check siblings at all and let each role post its honest verdict.
With shared tokens and parallel CI jobs, a deadlock can occur:
1. sonnet → REQUEST_CHANGES, security → escalates to REQUEST_CHANGES
2. Dev fixes, pushes
3. sonnet wants APPROVED but sees security REQUEST_CHANGES → re-escalates
4. security wants APPROVED but sees sonnet REQUEST_CHANGES → re-escalates
Mitigated by the `stale` flag (reviews from old commits are skipped), but within the same CI run with parallel jobs, the race is theoretically possible.
Best fix: separate tokens per role (see sister issue). Alternative: don't check siblings at all and let each role post its honest verdict.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
With shared tokens and parallel CI jobs, a deadlock can occur:
Mitigated by the
staleflag (reviews from old commits are skipped), but within the same CI run with parallel jobs, the race is theoretically possible.Best fix: separate tokens per role (see sister issue). Alternative: don't check siblings at all and let each role post its honest verdict.