coilyco-flight-deck/ward

Fork 0

Native PR merge returns Forgejo 405 on green mergeable PR #1168

New issue

Closed

opened 2026-07-13 04:11:20 +00:00 by coilyco-ops · 6 comments

coilyco-ops commented

2026-07-13 04:11:20 +00:00

Member

ward agent pr merge can get stuck on a PR that ward itself reports as green and Forgejo reports as mergeable.

Observed from a director surface on 2026-07-13 against coilyco-flight-deck/ward#1164:

ward ops forgejo pr view coilyco-flight-deck ward 1164 --query ... reported mergeable: true, merged: false, state: open, head be61274cbfb34afd77ee13d5555639b8d067a7af.
ward agent pr status coilyco-flight-deck/ward#1164 reported combined status success with all listed checks green.
ward agent pr merge coilyco-flight-deck/ward#1164 failed three times, including after a 30 second settle window, with: forgejo merge PR returned 405 Method Not Allowed: {"message":"Please try again later","url":"https://forgejo.coilysiren.me/api/swagger"}.

Wanted behavior:

The native merge command should diagnose this state instead of surfacing an opaque 405.
If Forgejo is recalculating mergeability, ward should wait/retry with a bounded settle loop.
If the target branch has a real server-side merge restriction, ward should report the missing condition or required operator action.
The director lane should not strand an otherwise green mergeable PR behind a transient or opaque Forgejo merge response.

This currently blocks reducing open PR pressure, which then blocks further issue dispatch and existing-branch repair.

`ward agent pr merge` can get stuck on a PR that ward itself reports as green and Forgejo reports as mergeable. Observed from a director surface on 2026-07-13 against `coilyco-flight-deck/ward#1164`: * `ward ops forgejo pr view coilyco-flight-deck ward 1164 --query ...` reported `mergeable: true`, `merged: false`, `state: open`, head `be61274cbfb34afd77ee13d5555639b8d067a7af`. * `ward agent pr status coilyco-flight-deck/ward#1164` reported combined status `success` with all listed checks green. * `ward agent pr merge coilyco-flight-deck/ward#1164` failed three times, including after a 30 second settle window, with: `forgejo merge PR returned 405 Method Not Allowed: {"message":"Please try again later","url":"https://forgejo.coilysiren.me/api/swagger"}`. Wanted behavior: * The native merge command should diagnose this state instead of surfacing an opaque 405. * If Forgejo is recalculating mergeability, ward should wait/retry with a bounded settle loop. * If the target branch has a real server-side merge restriction, ward should report the missing condition or required operator action. * The director lane should not strand an otherwise green mergeable PR behind a transient or opaque Forgejo merge response. This currently blocks reducing open PR pressure, which then blocks further issue dispatch and existing-branch repair.

coilyco-ops commented

2026-07-13 09:22:59 +00:00

Author

Member

Update from the burn-down session. After the ward-salvage lock debris was cleaned server-side, the session retested the native path: ward agent pr merge coilyco-flight-deck/ward#1169 still returned 405 Method Not Allowed with body message "Please try again later", so the stale ref locks are ruled out as the sole cause. Forgejo returns that 405 while a PR sits in the checking state, and every PR in this jam kept returning it for hours, which points at a wedged pull-request checker queue server-side. The related upstream reports are forgejo#680 (old PRs continuously checked) and go-gitea/gitea#34546 (stale lock files that no housekeeping job cleans). Kai can probe the queue on the admin monitor page or restart the forgejo deployment to flush it. The session cleared the jam without the API - it merged each PR branch into main locally, verified with ward build plus ward test plus pre-commit, and pushed the merge commit, then closed each PR naming its landing commit. The right native fix remains a bounded settle-retry plus surfacing the checking state instead of the opaque 405.

Update from the burn-down session. After the ward-salvage lock debris was cleaned server-side, the session retested the native path: `ward agent pr merge coilyco-flight-deck/ward#1169` still returned 405 Method Not Allowed with body message "Please try again later", so the stale ref locks are ruled out as the sole cause. Forgejo returns that 405 while a PR sits in the checking state, and every PR in this jam kept returning it for hours, which points at a wedged pull-request checker queue server-side. The related upstream reports are forgejo#680 (old PRs continuously checked) and go-gitea/gitea#34546 (stale lock files that no housekeeping job cleans). Kai can probe the queue on the admin monitor page or restart the forgejo deployment to flush it. The session cleared the jam without the API - it merged each PR branch into main locally, verified with ward build plus ward test plus pre-commit, and pushed the merge commit, then closed each PR naming its landing commit. The right native fix remains a bounded settle-retry plus surfacing the checking state instead of the opaque 405.

coilyco-ops added the

headless

labels

2026-07-14 06:50:06 +00:00

coilyco-ops commented

2026-07-14 09:12:33 +00:00

Author

Member

Fresh burn-down evidence from 2026-07-14: ward agent pr status coilyco-flight-deck/agentic-os#519 reported combined status success for ci / ward-doctor and ci / gate, but ward agent pr merge coilyco-flight-deck/agentic-os#519 returned Forgejo 405 Method Not Allowed with body {"message":"Please try again later","url":"https://forgejo.coilysiren.me/api/swagger"}. A follow-up status check still reported success, and the PR stayed open, so this instance did not hit the closed-unmerged failure mode from ward#1170.

Fresh burn-down evidence from 2026-07-14: `ward agent pr status coilyco-flight-deck/agentic-os#519` reported combined status success for `ci / ward-doctor` and `ci / gate`, but `ward agent pr merge coilyco-flight-deck/agentic-os#519` returned Forgejo 405 Method Not Allowed with body `{"message":"Please try again later","url":"https://forgejo.coilysiren.me/api/swagger"}`. A follow-up status check still reported success, and the PR stayed open, so this instance did not hit the closed-unmerged failure mode from ward#1170.

coilyco-ops commented

2026-07-14 09:51:37 +00:00

Author

Member

Fresh burn-down evidence from 2026-07-14: ward agent pr status coilyco-flight-deck/ward#1261 reported combined status success for test / test, but ward agent pr merge coilyco-flight-deck/ward#1261 returned Forgejo 405 Method Not Allowed with body {"message":"Please try again later","url":"https://forgejo.coilysiren.me/api/swagger"}. This occurred minutes after ward#1260 merged successfully through the same native path, so the failure is PR-specific or transient rather than a total merge-lane outage.

Fresh burn-down evidence from 2026-07-14: `ward agent pr status coilyco-flight-deck/ward#1261` reported combined status success for `test / test`, but `ward agent pr merge coilyco-flight-deck/ward#1261` returned Forgejo 405 Method Not Allowed with body `{"message":"Please try again later","url":"https://forgejo.coilysiren.me/api/swagger"}`. This occurred minutes after `ward#1260` merged successfully through the same native path, so the failure is PR-specific or transient rather than a total merge-lane outage.

coilyco-ops commented

2026-07-14 10:18:16 +00:00

Author

Member

WARDED_WORKFLOW: reservation-released

release details

Run never started. ward container reap released container engineer-codex-ward-1168 (--harness codex): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the launch intent it took is retracted. Nothing is running on this issue. It needs re-dispatch. A ward agent director re-queues it automatically. A manual ward agent retry no longer needs --override-reservation.

— Codex, via ward agent

WARDED_WORKFLOW: reservation-released <details><summary>release details</summary> Run never started. `ward container reap` released container `engineer-codex-ward-1168` (`--harness codex`): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the launch intent it took is retracted. Nothing is running on this issue. It needs re-dispatch. A `ward agent director` re-queues it automatically. A manual `ward agent` retry no longer needs `--override-reservation`. </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-14 10:58:10 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

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

Accepted by ward agent --harness codex (reserved 2026-07-14T10:58:09Z). 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#1168 · branch issue-1168 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1168 · ward v0.679.0 · dispatched 2026-07-14T10:57:51Z
Comment thread: 4 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-13T09:22:59Z), @coilyco-ops (2026-07-14T09:12:33Z), @coilyco-ops (2026-07-14T09:51:37Z), @coilyco-ops (2026-07-14T10:18:16Z)

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

— Codex, via ward agent

WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-ward-1168` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-14T10:58:09Z). 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#1168` · branch `issue-1168` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1168` · ward `v0.679.0` · dispatched `2026-07-14T10:57:51Z` - **Comment thread:** 4 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-13T09:22:59Z), @coilyco-ops (2026-07-14T09:12:33Z), @coilyco-ops (2026-07-14T09:51:37Z), @coilyco-ops (2026-07-14T10:18:16Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.679.0). </details> </details>  — Codex, via `ward agent`

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

2026-07-14 11:06:59 +00:00

Fix Forgejo PR merge settle loop #1277

coilyco-ops closed this issue

2026-07-14 11:08:41 +00:00

coilyco-ops commented

2026-07-14 11:09:07 +00:00

Author

Member

WARDED_WORKFLOW: #1277

details

review gate skipped by ~/.ward/config.yaml default
workflow: pull-request-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default

Felt steady once the retry loop re-read the live gate. Confidence is high. Surprise was Forgejo keeping the PR green while returning 405 until the settle loop retried. Follow-ups: none.

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1277 <details><summary>details</summary> review gate skipped by ~/.ward/config.yaml default workflow: pull-request-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default Felt steady once the retry loop re-read the live gate. Confidence is high. Surprise was Forgejo keeping the PR green while returning 405 until the settle loop retried. Follow-ups: none. </details>