Comment on PRs when warded PR workflows fail #813

New issue

Closed

opened 2026-07-09 16:20:58 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-09 16:20:58 +00:00

Member

Goal

When a warded workflow opens a pull request and then fails for any reason, ward should comment on both the linked issue and the pull request.

The PR comment should carry the same failure information as the issue comment, except the PR version should not say anything about releasing or clearing a reservation lock. Reservation lock handling is issue-owned state and reads wrong on the PR.

Current problem

Failure handling already produces useful issue comments for failed warded workflows. In PR workflows, the pull request is the active review surface too, so a failure that only appears on the issue leaves the PR stale or ambiguous.

This applies to any failure path after a PR exists, including CI failure, review/QA failure, merge failure, rebase/conflict failure, broker/container failure that is reported back into the workflow, or any other terminal workflow failure.

Scope

Find the shared failure-comment path used for issue comments in warded agent workflows.
For workflows that have opened or discovered a PR, post the same failure summary to the PR as well as the issue.
Keep issue comments unchanged, including any reservation-lock release wording that belongs there.
Adjust the PR variant so it omits reservation-lock release wording.
Avoid duplicate PR comments on repeated polling or retries. Follow the existing idempotency/signature convention if one exists.
Preserve behavior for direct-main workflows and workflows that never opened a PR.

Acceptance

A failing pull-request or pull-request-and-merge workflow comments on the linked issue and the PR.
The PR comment includes the same actionable failure details as the issue comment.
The PR comment does not mention releasing, clearing, or handing back a reservation lock.
Existing issue failure comments keep their current reservation-lock wording where appropriate.
Tests cover at least one PR workflow failure after PR creation and prove both comments are posted with the correct wording difference.
Tests cover that no PR comment is attempted when no PR exists.
Repo validation passes through ward.

## Goal When a warded workflow opens a pull request and then fails for any reason, ward should comment on both the linked issue and the pull request. The PR comment should carry the same failure information as the issue comment, except the PR version should not say anything about releasing or clearing a reservation lock. Reservation lock handling is issue-owned state and reads wrong on the PR. ## Current problem Failure handling already produces useful issue comments for failed warded workflows. In PR workflows, the pull request is the active review surface too, so a failure that only appears on the issue leaves the PR stale or ambiguous. This applies to any failure path after a PR exists, including CI failure, review/QA failure, merge failure, rebase/conflict failure, broker/container failure that is reported back into the workflow, or any other terminal workflow failure. ## Scope * Find the shared failure-comment path used for issue comments in warded agent workflows. * For workflows that have opened or discovered a PR, post the same failure summary to the PR as well as the issue. * Keep issue comments unchanged, including any reservation-lock release wording that belongs there. * Adjust the PR variant so it omits reservation-lock release wording. * Avoid duplicate PR comments on repeated polling or retries. Follow the existing idempotency/signature convention if one exists. * Preserve behavior for direct-main workflows and workflows that never opened a PR. ## Acceptance * A failing pull-request or pull-request-and-merge workflow comments on the linked issue and the PR. * The PR comment includes the same actionable failure details as the issue comment. * The PR comment does not mention releasing, clearing, or handing back a reservation lock. * Existing issue failure comments keep their current reservation-lock wording where appropriate. * Tests cover at least one PR workflow failure after PR creation and prove both comments are posted with the correct wording difference. * Tests cover that no PR comment is attempted when no PR exists. * Repo validation passes through ward.

coilyco-ops commented

2026-07-09 16:21:08 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-813 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T16:21:05Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#813 · branch issue-813 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-813 · ward v0.493.0 · dispatched 2026-07-09T16:21:05Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-813` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T16:21:05Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward#813` · branch `issue-813` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-813` · ward `v0.493.0` · dispatched `2026-07-09T16:21:05Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-09 16:32:35 +00:00

Comment on PRs when warded PR workflows fail #815

coilyco-ops closed this issue

2026-07-09 16:52:12 +00:00

coilyco-ops commented

2026-07-09 16:53:12 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: pull-request-and-merge; review summary: skipped: review gate skipped by --skip-review / --no-review-gate
felt steady after two merge-state reruns. confidence: high. surprise: Forgejo mergeability lagged behind the refreshed branch tip. follow-up: none.

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped: review gate skipped by --skip-review / --no-review-gate felt steady after two merge-state reruns. confidence: high. surprise: Forgejo mergeability lagged behind the refreshed branch tip. follow-up: none. </details>