[zoomote]

​Created by Roomote. Follow up by mentioning @roomote, in the web UI, or in Discord.

Related GitHub Issue

Part of #2089 (steps 3–4). PR #2091 carries steps 1–2 (mergeability retry and the unknown-read freeze). This PR does not close the issue on its own.

Description

The workflow kept has-conflicts inside the exclusive stateLabels group. That group holds the turn labels (awaiting-author, awaiting-coderabbit, awaiting-ready, awaiting-maintainer). Two different facts competed for one label slot: whose turn it is, and whether the branch has conflicts. The old conflict branch set has-conflicts instead of a turn label, so a conflicted PR lost its awaiting-author state. A legacy has-conflicts + awaiting-maintainer pair could also survive on the same PR.

Changes in .github/workflows/label-pr-review-state.yml:

• has-conflicts is no longer a member of stateLabels. Turn labels reconcile among themselves only.
• A new reconcileConflictFlag helper owns the flag. A known dirty read sets it. A known read that is not dirty removes it. While mergeability is unknown, no caller runs, so the flag freezes together with the turn labels (the [Fix] Review-state labels swap on unchanged PRs while GitHub computes mergeability #2091 behavior now covers the flag too).
• Both conflict branches (the first known dirty read and the maintainer-handoff recheck) set the flag and force the turn label to awaiting-author. A conflicted PR can never carry awaiting-maintainer.
• The CI-pending/failed branch and the final reconcile remove the flag on a known read. The configuration-error branch and the outer failure cleanup never touch the flag, because no known mergeability read decided anything there. A failed flag write marks its error with preserveStateLabels, so cleanup keeps the current labels exactly like the unknown-read freeze.

Unchanged behavior: known clean reads reconcile turn labels exactly as before. The conflict review gate, its guide text, and CodeRabbit deactivation in the conflict branch keep their current wording and effect. The stale-pr-clock workflow (#2077) is untouched; stale-pr-clock-workflow.test.ts:593 keeps passing because the stale step only reads labels.

Test Procedure

New tests in src/services/__tests__/pr-review-state-workflow.test.ts:

• carries awaiting-author and has-conflicts together, stable across consecutive runs (#2089): a known dirty read sets both labels, and a second run with the same dirty read writes no label at all.
• removes the has-conflicts flag on a known clean read without touching the turn label (#2089): the flag goes; awaiting-maintainer stays.
• keeps state labels when removing the has-conflicts flag fails (#2089): the failed flag write preserves the current labels and fails the run.

Updated tests: the conflict-branch tests now also assert awaiting-author; the flag-add-failure test asserts the new fail-closed message; the outer-cleanup test uses a turn label, because the flag no longer takes part in turn-label reconciliation. The unknown-mergeability tests from #2025 and #2091 already pin the flag freeze, and they pass unchanged.

Checks run locally:

• pnpm --dir src run test:workflow — 308 passed (4 files).
• pnpm --dir src run test:services — 1465 passed.
• pnpm --dir src run check-types — passed.
• pnpm --dir src exec eslint --prune-suppressions --max-warnings=0 services/__tests__/pr-review-state-workflow.test.ts — passed. No suppression count changed.
• pnpm test from the repository root — passed on re-run (13/13 turbo tasks). One run showed the 2 known extension.spec.ts parallel-load flakes. They pass in isolation and on re-run, with and without these changes (same pattern as the [Fix] Review-state labels swap on unchanged PRs while GitHub computes mergeability #2091 run).

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I reviewed my own code with care.
• Writing Style: The PR title and description use Simplified Technical English (ASD-STE100): short sentences, plain words, active voice, one idea per sentence, no contractions. Keep the title short and specific.
• Testing: New and/or updated tests have been added to cover my changes (if applicable).
• Visual Snapshot (UI changes only): Not applicable — no UI change.
• Documentation Impact: I checked if my changes need documentation updates (see "Documentation Updates" section below).
• Contribution Guidelines: I read and agree to the Contributor Guidelines.

Visual Snapshots

Not applicable — this change touches CI workflow logic only.

Videos (interaction / animation only)

Not applicable.

Documentation Updates

• No documentation updates are required.
• Yes, documentation updates are required. (Describe what to update, or link to a PR in the docs repository).

Re-verified during this change: Zoo-Code-Docs does not document the review-state labels or their exclusivity rules. A search across its docs, src, and sidebar files finds no mention of has-conflicts, the awaiting-* labels, coderabbit-review-active, or community-approved. No docs PR pairs with this change.

Additional Notes

Reviewer notes on the new semantics:

• "Known read that is not dirty" removes the flag. This includes blocked, unstable, or behind, not only a literal mergeable_state: "clean". A resolved conflict therefore does not keep a stale flag while CI runs.
• While mergeability stays unknown, the freeze also holds a stale flag in place. A legacy has-conflicts + awaiting-maintainer pair survives until some run reads a known value. A known dirty read then forces awaiting-author; a known non-dirty read removes the flag.
• Cost: the flag adds at most one label write per changed state per run. Reads, retries, and sweep behavior are unchanged from [Fix] Review-state labels swap on unchanged PRs while GitHub computes mergeability #2091.
• Still out of scope, per the issue: removing the push trigger (tracked in a separate issue) and the stale-pr-clock workflow ([Fix] Stale PR clock resets on bot activity so stale PRs never close #2077).

Get in Touch

Discord: 0x7777777_

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Repository: Zoo-Code-Org/Zoo-Code/.coderabbit.yaml
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 66ad1e3c-c0f4-4db1-8e25-c7136e78b3c3

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Review status

This PR was opened by an automated account. A human maintainer must verify the change intent, provenance, and validation before merging.

Current step: Required CI passed. Waiting for automated review of the latest commit.

If automated review does not start, a maintainer must restart it.

Review-state labels are managed by this workflow; do not edit them manually. community-approved is managed the same way — do not add or remove it manually. It signals a fresh community code approval for the current head as an advisory priority only; maintainer review is still required.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!