Blocked weighted approvals remain pending
阻塞中的加权批准保持 pending
The weighted approval commit status must distinguish an unmet merge condition from a failed policy evaluation. An effective `CHANGES_REQUESTED` review from a write-capable reviewer prevents a pull request from satisfying the approval policy, but it is a reversible review state rather than an evaluation failure. Publishing `failure` for that review state conflates the approval decision with the health of the publisher
English
Problem
The weighted approval commit status must distinguish an unmet merge condition from a failed policy evaluation. An effective CHANGES_REQUESTED review from a write-capable reviewer prevents a pull request from satisfying the approval policy, but it is a reversible review state rather than an evaluation failure.
Publishing failure for that review state conflates the approval decision with the health of the publisher. It also treats one unmet policy condition differently from a draft pull request or insufficient approval points, which remain pending while contributors can resolve them.
Decision
A completed weighted approval evaluation publishes pending when the pull request is a draft, has fewer than the required approval points, or has an effective CHANGES_REQUESTED review from a write-capable reviewer. A blocking review dominates the point total, so the status remains pending even when counted approvals reach the threshold.
The evaluation publishes success only when the pull request is ready, the point threshold is met, and no blocking review exists. The separate weighted approval publisher Actions job reports whether evaluation and status publication completed. An evaluation failure publishes an error commit status and fails that job.
Verification
Approval policy tests pin the threshold-reaching blocker case and the exact published pending payload. Workflow tests pin the separate publisher job name.
Alternatives considered
Publish failure for a blocking review. This keeps a visibly failed status until the review changes, but it represents an unmet and reversible merge condition as a malfunction and conflates policy outcome with publisher health.
Let approval points override a blocking review. This makes the score the only success condition, but it permits a successful status while a write-capable reviewer's effective decision still requests changes.
Consequences
Required-status branch rules block a pull request because pending does not satisfy the required status. Contributors can distinguish review work that remains from a failed approval evaluation, while the publisher job and error status retain the operational failure signal.
Consumers do not receive a failed commit status solely because a blocking review exists. They must inspect the status description or effective reviews when they need to distinguish a blocker from other pending approval conditions.
中文
问题
weighted approval commit status 必须区分尚未满足的合并条件与失败的策略评估。具有写权限的评审人所提交且仍然生效的 CHANGES_REQUESTED 评审会阻止 PR 满足批准策略，但它是一种可撤销的评审状态，而不是评估故障。
为这种评审状态发布 failure 会混淆批准决策与 publisher 的健康状态。它还会让一个尚未满足的策略条件区别于 draft PR 或批准点数不足；后两种情况在贡献者能够解决问题期间会保持 pending。
决策
完成的加权批准评估会在 PR 为 draft、批准点数少于要求，或具有写权限的评审人存在仍然生效的 CHANGES_REQUESTED 评审时发布 pending。阻塞性评审的优先级高于点数总和，因此即使计入的批准已经达到阈值，状态仍保持 pending。
只有在 PR 已进入 ready 状态、达到点数阈值且不存在阻塞性评审时，评估才发布 success。独立的 weighted approval publisher Actions job 报告评估和状态发布是否完成。评估故障会发布 error commit status，并使该 job 失败。
验证
批准策略测试锁定已达到阈值但仍有 blocker 的场景，以及准确发布的 pending payload。工作流测试锁定独立的 publisher job 名称。
考虑过的替代方案
为阻塞性评审发布 failure。 该方案会在评审改变之前保持明显的失败状态，但它会把尚未满足且可撤销的合并条件表示为故障，并混淆策略结果与 publisher 的健康状态。
允许批准点数覆盖阻塞性评审。 该方案会让分数成为唯一的成功条件，但也允许在具有写权限的评审人仍然有效地要求修改时发布成功状态。
后果
需要该状态的分支规则会阻止 PR，因为 pending 不满足必需状态。贡献者可以区分尚待处理的评审工作与失败的批准评估，而 publisher job 和 error 状态保留运行故障信号。
消费方不会仅因存在阻塞性评审而收到失败的 commit status。如果需要区分 blocker 与其他 pending 批准条件，它们必须检查状态描述或仍然生效的评审。