issue --json: read closure data on GitLab #667

New issue

claude · 2026-10-01T21:15:37Z

claude commented

2026-10-01 21:15:37 +00:00

Found during IW-651 (analysis). Deferred by Michal on 2026-10-01. Until this is done, iw issue <id> --json prints closure: {"kind": "notImplemented"} for this tracker. Forgejo implementation and closure rules: core/model/IssueState.scala, project-management/issues/IW-651/analysis.md.

GET /projects/:id/issues/:iid/closed_by lists closing MRs with state/merged_at; apply the Forgejo time-window rule. From GitLab documentation only, not tested.

Found during IW-651 (analysis). Deferred by Michal on 2026-10-01. Until this is done, `iw issue <id> --json` prints `closure: {"kind": "notImplemented"}` for this tracker. Forgejo implementation and closure rules: `core/model/IssueState.scala`, `project-management/issues/IW-651/analysis.md`. `GET /projects/:id/issues/:iid/closed_by` lists closing MRs with `state`/`merged_at`; apply the Forgejo time-window rule. From GitLab documentation only, not tested.

claude commented

2026-10-15 15:25:44 +00:00

Intake: needs-input
Workflow: waterfall
Reason: G1 (1 CLARIFY marker)
Analysis: project-management/issues/IW-667/analysis.md on branch IW-667

1. Should GitLab use the closing MR it recorded on the close event, or the 60 s window? (G1)

The IW-651 decision says GitLab uses the same 60 s time-window rule as Forgejo (IW-651 analysis L211), and the IW-667 issue body says the same. GitLab closes the issue in a background job after the merge, so the close can come late. One real gitlab.com issue closed 60.91 s after its merge, and an MR that closes 5 or more issues closes the 5th and later ones 5 minutes or more after the merge (analysis L65-L69). GitLab also records the closing MR on the close event, but nobody has read that field from a real instance yet, because that needs a token.

a) Use the MR that GitLab recorded on the close event. This replaces the rule in the IW-651 decision. The answer is exact for late closes. An MR merged into this project from a fork is found. An MR whose target is a different project gives unknown. This costs one more API call. Before the phase can merge, someone must run a check against a real GitLab project with a token (IW_CONTRACT_GLAB_PROJECT) that has one issue closed by a merge. No such project is set up for CI, so the merge waits for a human to set one up (analysis L231, L406-L407).
b) Keep the 60 s window, as decided in IW-651. This needs fewer API calls and nothing blocks the merge. A late close gives noMergedPullRequest, which consumers read as "failed".

Recommended: a). The window gives a wrong answer for every late close, and the one field nobody has read gets a check before merge.

Answer in a comment on this issue, per number, for example "1: a", or in your own words; intake reads it on its next iteration.

Intake: needs-input Workflow: waterfall Reason: G1 (1 CLARIFY marker) Analysis: project-management/issues/IW-667/analysis.md on branch IW-667 ### 1. Should GitLab use the closing MR it recorded on the close event, or the 60 s window? (G1) The IW-651 decision says GitLab uses the same 60 s time-window rule as Forgejo ([IW-651 analysis L211](https://code.iterative.works/iterative-works/iw-cli/src/branch/IW-667/project-management/issues/IW-651/analysis.md#L211)), and the IW-667 issue body says the same. GitLab closes the issue in a background job after the merge, so the close can come late. One real gitlab.com issue closed 60.91 s after its merge, and an MR that closes 5 or more issues closes the 5th and later ones 5 minutes or more after the merge ([analysis L65-L69](https://code.iterative.works/iterative-works/iw-cli/src/branch/IW-667/project-management/issues/IW-667/analysis.md#L65-L69)). GitLab also records the closing MR on the close event, but nobody has read that field from a real instance yet, because that needs a token. - **a) Use the MR that GitLab recorded on the close event.** This replaces the rule in the IW-651 decision. The answer is exact for late closes. An MR merged into this project from a fork is found. An MR whose target is a different project gives `unknown`. This costs one more API call. Before the phase can merge, someone must run a check against a real GitLab project with a token (`IW_CONTRACT_GLAB_PROJECT`) that has one issue closed by a merge. No such project is set up for CI, so the merge waits for a human to set one up ([analysis L231](https://code.iterative.works/iterative-works/iw-cli/src/branch/IW-667/project-management/issues/IW-667/analysis.md#L231), [L406-L407](https://code.iterative.works/iterative-works/iw-cli/src/branch/IW-667/project-management/issues/IW-667/analysis.md#L406-L407)). - **b) Keep the 60 s window, as decided in IW-651.** This needs fewer API calls and nothing blocks the merge. A late close gives `noMergedPullRequest`, which consumers read as "failed". **Recommended: a)**. The window gives a wrong answer for every late close, and the one field nobody has read gets a check before merge. Answer in a comment on this issue, per number, for example "1: a", or in your own words; intake reads it on its next iteration.

claude added the

needs-input

label

2026-10-15 15:25:44 +00:00

Sign in to join this conversation.