Treat Forgejo pull_request null as an issue, not a PR #985

New issue

Closed

opened 2026-07-10 09:18:34 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-10 09:18:34 +00:00

Member

Forgejo issue list payloads include a pull_request key on normal issues with a JSON null value. A client that filters PRs with key presence instead of a non-null value misclassifies normal issues as pull requests.

Observed from a read-only director surface on 2026-07-10 while scanning coilyco-flight-deck/ward and coilyco-flight-deck/agentic-os:

GET /api/v1/repos/coilyco-flight-deck/ward/issues?state=open&page=1&limit=10 returned normal issue #982 with a pull_request key whose value was null.
GET /api/v1/repos/coilyco-flight-deck/agentic-os/issues?state=open&page=1&limit=10 returned normal issue #419 with pull_request: null, while PR #420 had a real pull_request object.
An initial scanner that used Python's if "pull_request" in issue reported open issues 0 for both repos despite dozens of open issues.

This is an easy regression to introduce in ward's issue, queue, and director code because the GitHub-style shape often encourages key-presence checks.

Expected behavior:

Shared Forgejo issue classification helpers should treat an item as a PR only when pull_request is present and non-null.
Add or update tests using fixtures for both pull_request: null normal issues and real PR objects.
Any director queue/backlog scanner should use the helper instead of ad hoc key checks.

Forgejo issue list payloads include a `pull_request` key on normal issues with a JSON `null` value. A client that filters PRs with key presence instead of a non-null value misclassifies normal issues as pull requests. Observed from a read-only director surface on 2026-07-10 while scanning `coilyco-flight-deck/ward` and `coilyco-flight-deck/agentic-os`: * `GET /api/v1/repos/coilyco-flight-deck/ward/issues?state=open&page=1&limit=10` returned normal issue `#982` with a `pull_request` key whose value was `null`. * `GET /api/v1/repos/coilyco-flight-deck/agentic-os/issues?state=open&page=1&limit=10` returned normal issue `#419` with `pull_request: null`, while PR `#420` had a real pull_request object. * An initial scanner that used Python's `if "pull_request" in issue` reported `open issues 0` for both repos despite dozens of open issues. This is an easy regression to introduce in ward's issue, queue, and director code because the GitHub-style shape often encourages key-presence checks. Expected behavior: * Shared Forgejo issue classification helpers should treat an item as a PR only when `pull_request` is present and non-null. * Add or update tests using fixtures for both `pull_request: null` normal issues and real PR objects. * Any director queue/backlog scanner should use the helper instead of ad hoc key checks.

coilyco-ops added the

headless

labels

2026-07-10 09:18:34 +00:00

coilyco-ops commented

2026-07-10 09:18:45 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T09:18:44Z). 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#985 · branch issue-985 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-985 · ward v0.569.0 · dispatched 2026-07-10T09:18:44Z
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.569.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-985` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T09:18:44Z). 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#985` · branch `issue-985` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-985` · ward `v0.569.0` · dispatched `2026-07-10T09:18:44Z` - **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.569.0). </details> </details>  — Codex, via `ward agent`

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

2026-07-10 09:27:48 +00:00

fix(forgejo): treat null pull_request as issue #989

coilyco-ops closed this issue

2026-07-10 09:30:57 +00:00

coilyco-ops commented

2026-07-10 09:31:24 +00:00

Author

Member

WARD-OUTCOME: merge-ready

details

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

felt: straightforward after swapping the shared Forgejo feed classifier and updating the stale fixtures

confidence: high

surprises: the repo test suite needed WARD_TARGET_OWNER and WARD_TARGET_REPO cleared for the baked-default config tests

follow-ups: none

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default; CI green felt: straightforward after swapping the shared Forgejo feed classifier and updating the stale fixtures confidence: high surprises: the repo test suite needed WARD_TARGET_OWNER and WARD_TARGET_REPO cleared for the baked-default config tests follow-ups: none </details>