Fix ward promote failure after PR-pressure merge #1323

New issue

Closed

opened 2026-07-15 05:30:30 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-15 05:30:30 +00:00

Member

Problem

The ward main promotion workflow failed after merging PR #1299.

Evidence from the director heartbeat on 2026-07-15:

Forgejo Actions run: 8253 (#2096)
Workflow: promote.yml
Event/ref: push to main
Commit/title: PR-pressure redispatch should accept PR refs without hidden branch flags (#1299)
Conclusion: failure

This leaves main unhealthy even though PR #1299 had green PR CI and merged cleanly.

Task

Inspect the failed promote run, identify whether the failure is a transient release/promote issue or a regression introduced by #1299, and land the narrow fix or safe rerun path needed to restore green main promotion.

Acceptance criteria

The cause of run 8253 is documented in the issue or PR.
Ward main promotion is green again, or the run is safely rerun and confirmed green if it was purely transient.
Any code/config fix has passing PR CI before merge.

## Problem The ward main promotion workflow failed after merging PR #1299. Evidence from the director heartbeat on 2026-07-15: * Forgejo Actions run: 8253 (#2096) * Workflow: `promote.yml` * Event/ref: push to `main` * Commit/title: `PR-pressure redispatch should accept PR refs without hidden branch flags (#1299)` * Conclusion: failure This leaves main unhealthy even though PR #1299 had green PR CI and merged cleanly. ## Task Inspect the failed promote run, identify whether the failure is a transient release/promote issue or a regression introduced by #1299, and land the narrow fix or safe rerun path needed to restore green main promotion. ## Acceptance criteria * The cause of run 8253 is documented in the issue or PR. * Ward main promotion is green again, or the run is safely rerun and confirmed green if it was purely transient. * Any code/config fix has passing PR CI before merge.

coilyco-ops commented

2026-07-15 05:46:33 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

Holder: launch intent for container engineer-codex-ward-1323 on host kais-macbook-pro-2.local.

Accepted by ward agent --harness codex (reserved 2026-07-15T05:46:32Z). Concurrent ward agent runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). --override-reservation 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#1323 · branch issue-1323 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1323 · ward v0.697.0 · dispatched 2026-07-15T05:46:19Z
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.697.0).

— Codex, via ward agent

WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-ward-1323` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T05:46:32Z). Concurrent `ward agent` runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). `--override-reservation` 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#1323` · branch `issue-1323` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1323` · ward `v0.697.0` · dispatched `2026-07-15T05:46:19Z` - **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.697.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-15 05:51:43 +00:00

docs: note transient promote failures

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

2026-07-15 05:52:02 +00:00

docs: note transient promote failures #1329

coilyco-ops closed this issue

2026-07-15 05:53:27 +00:00

coilyco-ops commented

2026-07-15 05:53:57 +00:00

Author

Member

WARDED_WORKFLOW: #1329

details

workflow: pull-request-and-merge; review summary: skipped intentionally because temporary ward default pending brokered QA
felt: straightforward, mostly documentation after confirming 8253 was transient/superseded
confidence: high
surprises: later promote runs 8255, 8271, and 8276 were green
follow-ups: none

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1329 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped intentionally because temporary ward default pending brokered QA felt: straightforward, mostly documentation after confirming 8253 was transient/superseded confidence: high surprises: later promote runs 8255, 8271, and 8276 were green follow-ups: none </details>