fix(bot): keep review labels in sync when a fork PR is reviewed - #3121
Conversation
review-state.yml takes reviews through pull_request_review, and GitHub runs that event for a fork PR with a read-only GITHUB_TOKEN. The label write fails, the script logs it as a warning, and the run still passes, so on community PRs the review/* label waits for the six-hourly sweep. That goes for emdashbot's reviews and for maintainers' alike. emdash-bot already receives every pull_request_review delivery and holds a token that can write labels on fork PRs. A review on a fork PR now recomputes the label there, with the workflow's rules, so the next sweep agrees with what the bot set. The workflow skips those reviews and keeps same-repo PRs, so each review has one writer. Reviews on the bot's own fix PRs are handled as before.
TRIAGE.md described the issue bot's main commands and nine of its labels, but not the commands a triager needs to stop or undo its work (decline, take over, hand back, reopen, reset), the verdict and terminal labels an issue can carry, or where the full generated reference lives. It also left out when the review bot does not review: drafts, bot-authored PRs, and new commits. The guide said the review/* labels are applied by workflows; emdash-bot now applies them after a review on a fork PR, so both mentions say "automatically" instead. It also said area labels on issues are a human call, while the triage pass adds them.
|
Scope checkThis PR changes 513 lines across 9 files. Large PRs are harder to review and more likely to be closed without review. If this scope is intentional, no action needed. A maintainer will review it. If not, please consider splitting this into smaller PRs. See CONTRIBUTING.md for contribution guidelines. |
@emdash-cms/admin
@emdash-cms/auth
@emdash-cms/auth-atproto
@emdash-cms/blocks
@emdash-cms/cloudflare
@emdash-cms/contentful-to-portable-text
emdash
create-emdash
@emdash-cms/gutenberg-to-portable-text
@emdash-cms/plugin-cli
@emdash-cms/plugin-test
@emdash-cms/plugin-types
@emdash-cms/registry-client
@emdash-cms/registry-lexicons
@emdash-cms/registry-moderation
@emdash-cms/registry-verification
@emdash-cms/sandbox-workerd
@emdash-cms/x402
@emdash-cms/plugin-ai-moderation
@emdash-cms/plugin-atproto
@emdash-cms/plugin-audit-log
@emdash-cms/plugin-color
@emdash-cms/plugin-embeds
@emdash-cms/plugin-field-kit
@emdash-cms/plugin-forms
@emdash-cms/plugin-webhook-notifier
commit: |
![emdashbot[bot]](https://avatars.githubusercontent.com/in/3255304?s=60&v=4){kind=small}
There was a problem hiding this comment.
The approach is the right one: fork-PR reviews get a read-only token in review-state.yml, so moving the label write to the already-trusted emdash-bot GitHub App avoids elevating the workflow to pull_request_target for review events. The review-state rules in infra/emdash-bot/.flue/lib/review-state.ts mirror the workflow's logic (count maintainer/bot reviews, ignore the author's own reviews, ignore merge commits when deciding needs-rereview, etc.), and the new webhook path correctly skips same-repo and bot-authored PRs so there is still only one writer per review under normal circumstances. Tests cover both the normalizer unit cases and a workers-pool end-to-end run for a contributor PR.
I checked the diff, the full changed files, the state machine (machine.ts / BOT_STATE_MACHINE.md), the triage agent skill, and the flue-review auto-review gate. The implementation is clean and the docs line up with the machine. I do have a few edge-case/robustness notes — none of them are blockers for the stated bug fix, but worth tightening before merge.
github-actions
Bot
added
review/awaiting-author
2 participants
What does this PR do?
Moves a fork PR's
review/*label when the PR is reviewed, not on the next six-hourly sweep.review-state.ymltakes reviews throughpull_request_review, which GitHub runs for a fork PR with a read-only token, so the label write fails as a warning while the run passes (example). The same happens after a maintainer's review.emdash-bot already receives these deliveries, and its App token can write labels on fork PRs. A review on a fork PR now recomputes the label there with the workflow's rules, so the sweep agrees with it. The workflow skips those reviews, where it cannot write labels, and still handles same-repo PRs, so each review has one writer. A PR from a deleted fork has no head repository, so the workflow skips its reviews too and the bot writes its label. Creating the four labels stays with the workflow, which checks for them on every run. The bot skips bot-authored PRs by
type: Botor a[bot]login, the login check it already applies to actors; GitHub App accounts carry both. The bot's own fix PRs are handled as before.The second commit fills the gaps in what TRIAGE.md says about the bot, as requested in
#contributingon Discord:decline,take over/hand back,reopenandreset, the eight lifecycle labels it didn't list, when the review bot skips a PR (drafts, bot-authored PRs, new commits), and a link to the generatedBOT_STATE_MACHINE.md. Where the guide said workflows set the review labels, it now says "automatically", and it notes that triage adds area labels to issues. The bot also accepts its commands from triagers (a triager's@emdashbot triageon #3022 started a run within seconds). The guide keeps calling them maintainer commands and doesn't say whether triagers should use them.Type of change
Checklist
pnpm typecheckpassespnpm lintpassespnpm testpasses (or targeted tests for my change)pnpm formathas been runmessages.pochanges except in translation PRs — a workflow extracts catalogs on merge tomain. (n/a: no admin UI change)@emdash-cms/emdash-botis private)AI-generated code disclosure
Screenshots / test output
Not applicable for screenshots.
review/needs-reviewtoreview/awaiting-author, fails onmain, where the delivery is skipped.pnpm testininfra/emdash-bot: 358 unit and 91 workers-pool tests pass. No CI workflow runs this package, so its tests and typecheck ran locally.