Skip to content

[Reliability] Propagate scheduler mutation failures to a non-passing workflow result #894

Open

Description

@seonghobae

Problem

scripts/ci/pr_review_merge_scheduler.py::main() deliberately isolates PR-local mutation failures: it converts a caught RuntimeError into an action_error decision and continues inspecting the rest of the queue. That isolation is useful, but the CLI then unconditionally returns 0.

As a result, an update, merge, auto-merge, or dispatch mutation can fail, appear only in the structured summary as action_error, and still leave the scheduler job/workflow with a passing process result. The current tests explicitly assert this behavior.

Impact

A green scheduler check can be mistaken for successful mechanical governance even though a requested mutation failed. This weakens operational alerting and makes consumers parse logs or JSON to discover a material action failure.

Acceptance criteria

  • Preserve PR isolation: one failed mutation must not prevent later PRs from being inspected.
  • After the full bounded scan, emit the existing structured per-PR summary.
  • Return a non-zero terminal result when one or more material mutation/dispatch attempts ended in action_error.
  • Keep ordinary policy states such as wait, blocked, skip, or deferred capacity distinguishable from execution failure.
  • Ensure the reusable/required workflow exposes the failure without losing the summary artifact/job summary.
  • Add regression coverage for:
    • one action_error followed by an unaffected PR;
    • multiple action_error decisions;
    • no-action-error success;
    • structured output retained before terminal failure;
    • workflow consumer propagation.
  • Document whether a targeted single-PR run and an organization sweep use the same terminal policy.

Evidence

  • scripts/ci/pr_review_merge_scheduler.py catches RuntimeError per PR and creates Decision(..., "action_error", ...), then returns 0.
  • tests/test_pr_review_merge_scheduler.py::test_main_keeps_scanning_after_action_error and the update-branch 403/422 test assert that the CLI returns 0 while the summary contains action_error.

Related work

This issue is about terminal workflow truthfulness, not credential selection or queue serialization.

Activity

  1. added
    area: apiAPI, protocol, event, or external contract
    area: authAuthentication, authorization, identity, or tenant isolation
    area: ci-cdCI, GitHub Actions, checks, release, or supply chain
    area: operationsOperability, observability, readiness, SLO, backup, or retention
    status: blockedBlocked by conflict, dependency, or required prerequisite
    type: featureNew or expanded product capability
    on Aug 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: apiAPI, protocol, event, or external contractarea: authAuthentication, authorization, identity, or tenant isolationarea: ci-cdCI, GitHub Actions, checks, release, or supply chainarea: operationsOperability, observability, readiness, SLO, backup, or retentionbugSomething isn't workingpriority: mediumNormal-priority or P2 workstatus: blockedBlocked by conflict, dependency, or required prerequisitetype: featureNew or expanded product capability

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions