Comment fetch: the oldest-first order and the comment-shape probes are not tested for every adapter #783

New issue

claude · 2026-10-11T00:47:15Z

claude commented

2026-10-11 00:47:15 +00:00

Split off from the IW-700 analysis (project-management/issues/IW-700/analysis.md, Defects 1 and 4) by the answer at #700 (comment). IW-700 keeps the GitLab comment-fetch not-found message and the failed-comment-fetch harness tests. Found in IW-610 (review-phase-02-20261003-055441.md, architecture and testing).

What is wrong:

IssueFormatter.formatComments (core/output/IssueFormatter.scala:54) prints the heading Comments (oldest first): but keeps the order it gets. Only the five adapters sort. The port states the order as one Scaladoc line copied on five methods (core/commands/CommandEnv.scala:403-445), and only GitLab, YouTrack and Linear have an order test at the level of the public fetch function. GitHub and Forgejo test only their parsers.
The gh contract probe for the comment shape (test/contract/gh_adapter_contract.bats:53-82) always skips, because its fixture iterative-works/iw-cli#1 is a merged pull request with no comments, in an archived repository. test/contract/forgejo_api_contract.bats has no comment probe.

Fix: state the order for each tracker in the Scaladoc of each TrackerOps.fetch*IssueComments (the API's own order and its source, and that the adapter returns IssueComment.oldestFirst); add a fetch-level order test to GitHubClientTest and ForgejoClientTest; set GH_FIXTURE_ISSUE to 90 and make a zero-comment fixture fail, not skip; add a comment-shape probe to forgejo_api_contract.bats. IW-700 writes the not-found meaning into the same Scaladoc; the part that lands second adds to it. Land after IW-672 (PR #735) and IW-749, which change the same lines.

Estimate: 1.5-3.5 hours (order contract 1-2h, contract probes 0.5-1.5h).

The analysis text of the two defects follows, as IW-700 wrote it. The reproduction program Iw700Repro.scala and the probe script probes.sh are in the IW-700 analysis under Defect 2; sections D1a and D1b of the program, and the D1 and D4 sections of the script, belong to this part.

Probe output for this part (from probes.sh, exit 0):

== D4: gh contract fixture iterative-works/iw-cli#1 ==
{"comments":[],"number":1,"state":"MERGED"}
{"isArchived":true}
== D4: candidate fixture #90 (issue, archived repo) ==
{"comments":[{"bodyType":"string","createdAt":"2026-01-05T15:35:23Z","login":"mprihoda"},{"bodyType":"string","createdAt":"2026-01-19T12:54:25Z","login":"mprihoda"}],"number":90,"state":"CLOSED"}
== D1: Forgejo comments order (no sort parameter exists) ==
{
  "count": 6,
  "ascending": true
}

Defect 1: The "oldest first" heading is not held anywhere above the adapters

Reproduction Steps

Environment: iw-cli worktree /home/mph/Devel/iw/iw-cli-IW-700 at branch IW-700 (HEAD d9e76182), Scala 3.3.7, scala-cli. The program runs against the Mill test runtime classpath (core classes plus FakeCommandEnv).

Prerequisites:

env -u JDK_JAVA_OPTIONS ./mill show core.test.runClasspath has been run (it compiles core and the test fixtures).

Steps to reproduce:

Give IssueFormatter.formatComments two comments, newest first.
Script FakeTracker to return the same list newest first, then run iw issue SAMP-7 --comments through Issue.run.

Expected behavior: Under Comments (oldest first): the older comment comes first.
Actual behavior: The newer comment comes first under the "oldest first" heading, in both the formatter and the command.

Reproducibility: Always, for input that is not sorted. Through the real adapters: never today, because all five sort (see Hypothesis 2).

The reproduction program Iw700Repro.scala is in the IW-700 analysis under Defect 2. Output of its D1 sections (exit 0):

== D1a: formatComments with a newest-first list ==
Comments (oldest first):
  newer  2026-09-22T00:00:00Z
    written second

  older  2026-09-21T00:00:00Z
    written first

== D1b: iw issue --comments when the port answers newest first ==
exit=0
Comments (oldest first):
  newer  2026-09-22T00:00:00Z
    written second

  older  2026-09-21T00:00:00Z
    written first

Root Cause Hypotheses

Hypothesis 1: The order is an adapter duty that nothing above the adapters holds ⭐ Most Likely

Evidence:

The port states the order only as one Scaladoc line, the same on five methods (CommandEnv.scala:403-445, "Every comment of one issue, oldest first"). The line does not say what each tracker API returns or how the adapter enforces the order.
formatComments renders "in the order given" (IssueFormatter.scala:49-50). IssueFormatterTest "formatComments keeps the given order" pins on purpose that it does not sort (IW-610 phase-02-context.md:337).
The repro shows that output from any port implementation that does not sort reaches the user under the "oldest first" heading.

Likelihood: High (confirmed by the repro and by reading the code).

Investigation approach:

Done: IssueComment.oldestFirst is used in all five adapters: LinearClient.scala:110, YouTrackClient.scala:71, GitHubClient.scala:414, ForgejoClient.scala:181, GitLabClient.scala:327.
Done: the order tests per adapter. GitLab (GitLabClientTest:1199 parse, :1296 fetch), YouTrack (YouTrackClientTest:345 fetch), Linear (LinearClientMockTest:570 fetch across cursor pages), GitHub (GitHubClientTest:1132 parse only), Forgejo (ForgejoClientTest:396 parse only).

Fix strategy:

Decided: the adapters keep the order duty. The recorded IW-610 decision says so (analysis Domain layer, phase-01-context.md:117, phase-02-context.md:273), and the IW-700 Fix line ("make the comments contract explicit per adapter") agrees. A recorded decision settles this, so this analysis has no CLARIFY marker here.
Rejected: sorting again in formatComments. That reverses the recorded decision and adds a second place that owns the order.
Rejected: an opaque "sorted comments" type. It would change five port signatures, five live bindings and the fake to hold a guarantee that five adapter tests already hold. YAGNI.
Make the contract explicit on each TrackerOps.fetch*IssueComments. Replace the copied line with Scaladoc for that tracker. It states (a) the API's own order and its source, (b) that the adapter returns IssueComment.oldestFirst (ties keep the API order), and (c) what a not-found Left means (IW-700 Defect 2 writes that part). The per-tracker order facts:
- GitHub: no documented default. gh issue view --json comments returned ascending createdAt on cli/cli#13840 (149 comments) and iterative-works/iw-cli#90.
- GitLab: the documented default is sort=desc, order_by=created_at (docs.gitlab.com/api/notes, "List project issue notes"). The adapter asks for sort=asc&order_by=created_at.
- Linear: "By default results are ordered by createdAt field" (linear.app/developers/pagination). The direction is not documented.
- YouTrack: the order is not documented (devportal resource-api-issues-issueID-comments). Only fields, $skip and $top exist.
- Forgejo: the endpoint takes only since and before (code.iterative.works swagger.v1.json). Issue 636 returned 6 comments in ascending order.
Add a fetch-level order test to GitHubClientTest and ForgejoClientTest, with the same name in all five suites: "fetchIssueComments returns comments oldest first when the API answers newest first". Then each adapter's public fetch function, not only its parser, holds the contract.
Change the formatComments Scaladoc to say that the caller passes comments oldest first, as TrackerOps promises. Keep the "keeps the given order" test, because it pins the decision.
Estimated effort: 1-2 hours.

Risk of fix: Low. The change is documentation plus two tests. Production code does not change.

Hypothesis 2: An adapter returns comments that are not sorted today

Evidence against: All five adapters call IssueComment.oldestFirst (see the line references above), and each suite has an order test.

Likelihood: Low (ruled out by reading the code).

Investigation approach:

Done. The new fetch-level tests from Hypothesis 1 keep it ruled out.

Fix strategy: None.

Risk of fix: Not applicable.

Hypothesis 3: YouTrack paging relies on an order that is not documented

Evidence: YouTrackClient.fetchIssueComments pages with $skip, and the YouTrack comments endpoint documents no ordering parameter and no guaranteed order. If the server order is not stable between page requests, a page boundary could drop or repeat a comment. oldestFirst cannot fix that.

Likelihood: Low (nobody has observed it, and no YouTrack instance was available to probe).

Investigation approach:

Fetch a YouTrack issue with more than 100 comments with $top=100&$skip=0 and $skip=100 twice, and compare the ids.

Fix strategy: Out of scope for this issue. The Defect 1 Scaladoc for YouTrack names this assumption. Record it as one line in FOLLOW-UPS.md.

Risk of fix: Not applicable.

Defect 4: The gh contract probe for the comment shape never runs

Reproduction Steps

Environment: gh authenticated to github.com (this machine: account mprihoda), bats.

Steps to reproduce:

cd /home/mph/Devel/iw/iw-cli-IW-700 && bats --tap -f 'issue view --json returns' test/contract/gh_adapter_contract.bats
Run probes.sh (section D4 above).

Expected behavior: The probe checks author.login, createdAt and body of a real comment.
Actual behavior: Bats output (exit 0):

1..1
ok 1 gh issue view --json returns the keys iw-cli reads (number,title,state,assignees,body,comments) # skip fixture issue has no comments; the comment shape cannot be checked

The skip comes from gh_adapter_contract.bats:75-77. The probe shows that the fixture iterative-works/iw-cli#1 is a merged pull request with "comments":[], in a repository with "isArchived":true.

Reproducibility: Always.

Root Cause Hypotheses

Hypothesis 1: The fixture has no comments and cannot get any ⭐ Most Likely

Evidence:

Probe: #1 has state MERGED, comments: []. The repository is archived.
GitHub docs (Archiving repositories): in an archived repository "issues, pull requests, … comments and permissions become read-only. To make changes in an archived repository, you must unarchive the repository first." So the first fix that the issue proposes ("add a comment to the fixture issue") is not possible while the mirror is archived. The issue gives a second fix ("point the probe at an issue with comments"), so this is not a question for a human.
iterative-works/iw-cli#90 is an issue (state CLOSED) with 2 comments, each with a string author.login, createdAt and body (probe). Because the repository is archived, the fixture cannot change.

Likelihood: High (confirmed).

Investigation approach:

Done.

Fix strategy:

Decided: set GH_FIXTURE_ISSUE to 90. One fixture serves both auth-gated issue view probes. A real issue is a better fixture for gh issue view than a pull request. Write in the comment that the mirror is archived, so the fixture cannot change.
Replace the skip at :75-77 with a failure. A frozen fixture with zero comments means that gh changed its output or that the fixture is gone. A silent skip is the defect this issue reports.
Decided: no order assertion in the contract tier. Each adapter sorts, so iw does not depend on the API order (Defect 1). Contract tests pin what iw does depend on.
For parity: add a comment-shape probe to test/contract/forgejo_api_contract.bats. It runs anonymously against the public iterative-works/iw-cli issue 636 (6 comments; the fields user.login, created_at and body are what ForgejoClient.parseIssueCommentsResponse reads). With it, every adapter that has a contract file has a comment probe. GitLab already has one (glab_adapter_contract.bats:87-114). Linear and YouTrack have no contract file.
Estimated effort: 0.5-1.5 hours.

Risk of fix: Low. Contract tests run only nightly and on contract-labelled pull requests.

Hypothesis 2: In CI, the probe skips before it reaches the fixture

Evidence: The log of the nightly contract job (run on 33042e12, job 4040, 2026-10-07 03:21 UTC, read through the Forgejo Actions API) shows:

ok 7 gh issue view --json returns the keys iw-cli reads (number,title,state,assignees,body) # skip gh not authenticated (set up gh auth or run without --json-shape tests)
ok 7 glab issue view --output json returns the keys iw-cli reads (iid,title,state,assignees,description) # skip glab not authenticated

ci.yml:242-244 sets GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}. On Forgejo Actions that token comes from Forgejo, so gh auth status --hostname github.com fails. That run came before the IW-610 merge, but the auth mechanism has not changed since.

Likelihood: High (confirmed from the CI log).

Investigation approach:

Done.

Fix strategy: Outside the issue text. A real github.com token in CI is a secret that a human must provision. Record it as one line in FOLLOW-UPS.md. The ci.yml comment "so the JSON-shape tests don't skip on the nightly run" is false on this forge. Until that follow-up is done, the Defect 4 fix runs on authenticated developer machines and on contract-labelled pull requests only.

Risk of fix: Not applicable.

Split off from #700.

Split off from the IW-700 analysis (`project-management/issues/IW-700/analysis.md`, Defects 1 and 4) by the answer at https://code.iterative.works/iterative-works/iw-cli/issues/700#issuecomment-4571. IW-700 keeps the GitLab comment-fetch not-found message and the failed-comment-fetch harness tests. Found in IW-610 (`review-phase-02-20261003-055441.md`, architecture and testing). **What is wrong:** - `IssueFormatter.formatComments` (`core/output/IssueFormatter.scala:54`) prints the heading `Comments (oldest first):` but keeps the order it gets. Only the five adapters sort. The port states the order as one Scaladoc line copied on five methods (`core/commands/CommandEnv.scala:403-445`), and only GitLab, YouTrack and Linear have an order test at the level of the public fetch function. GitHub and Forgejo test only their parsers. - The gh contract probe for the comment shape (`test/contract/gh_adapter_contract.bats:53-82`) always skips, because its fixture `iterative-works/iw-cli#1` is a merged pull request with no comments, in an archived repository. `test/contract/forgejo_api_contract.bats` has no comment probe. **Fix:** state the order for each tracker in the Scaladoc of each `TrackerOps.fetch*IssueComments` (the API's own order and its source, and that the adapter returns `IssueComment.oldestFirst`); add a fetch-level order test to `GitHubClientTest` and `ForgejoClientTest`; set `GH_FIXTURE_ISSUE` to `90` and make a zero-comment fixture fail, not skip; add a comment-shape probe to `forgejo_api_contract.bats`. IW-700 writes the not-found meaning into the same Scaladoc; the part that lands second adds to it. Land after IW-672 (PR #735) and IW-749, which change the same lines. **Estimate:** 1.5-3.5 hours (order contract 1-2h, contract probes 0.5-1.5h). The analysis text of the two defects follows, as IW-700 wrote it. The reproduction program `Iw700Repro.scala` and the probe script `probes.sh` are in the IW-700 analysis under Defect 2; sections D1a and D1b of the program, and the D1 and D4 sections of the script, belong to this part. Probe output for this part (from `probes.sh`, exit 0): ``` == D4: gh contract fixture iterative-works/iw-cli#1 == {"comments":[],"number":1,"state":"MERGED"} {"isArchived":true} == D4: candidate fixture #90 (issue, archived repo) == {"comments":[{"bodyType":"string","createdAt":"2026-01-05T15:35:23Z","login":"mprihoda"},{"bodyType":"string","createdAt":"2026-01-19T12:54:25Z","login":"mprihoda"}],"number":90,"state":"CLOSED"} == D1: Forgejo comments order (no sort parameter exists) == { "count": 6, "ascending": true } ``` #### Defect 1: The "oldest first" heading is not held anywhere above the adapters ##### Reproduction Steps **Environment:** iw-cli worktree `/home/mph/Devel/iw/iw-cli-IW-700` at branch IW-700 (HEAD `d9e76182`), Scala 3.3.7, scala-cli. The program runs against the Mill test runtime classpath (core classes plus `FakeCommandEnv`). **Prerequisites:** - `env -u JDK_JAVA_OPTIONS ./mill show core.test.runClasspath` has been run (it compiles core and the test fixtures). **Steps to reproduce:** 1. Give `IssueFormatter.formatComments` two comments, newest first. 2. Script `FakeTracker` to return the same list newest first, then run `iw issue SAMP-7 --comments` through `Issue.run`. **Expected behavior:** Under `Comments (oldest first):` the older comment comes first. **Actual behavior:** The newer comment comes first under the "oldest first" heading, in both the formatter and the command. **Reproducibility:** Always, for input that is not sorted. Through the real adapters: never today, because all five sort (see Hypothesis 2). The reproduction program `Iw700Repro.scala` is in the IW-700 analysis under Defect 2. Output of its D1 sections (exit 0): ``` == D1a: formatComments with a newest-first list == Comments (oldest first): newer 2026-09-22T00:00:00Z written second older 2026-09-21T00:00:00Z written first == D1b: iw issue --comments when the port answers newest first == exit=0 Comments (oldest first): newer 2026-09-22T00:00:00Z written second older 2026-09-21T00:00:00Z written first ``` ##### Root Cause Hypotheses ###### Hypothesis 1: The order is an adapter duty that nothing above the adapters holds ⭐ Most Likely **Evidence:** - The port states the order only as one Scaladoc line, the same on five methods (`CommandEnv.scala:403-445`, "Every comment of one issue, oldest first"). The line does not say what each tracker API returns or how the adapter enforces the order. - `formatComments` renders "in the order given" (`IssueFormatter.scala:49-50`). `IssueFormatterTest` "formatComments keeps the given order" pins on purpose that it does not sort (IW-610 `phase-02-context.md:337`). - The repro shows that output from any port implementation that does not sort reaches the user under the "oldest first" heading. **Likelihood:** High (confirmed by the repro and by reading the code). **Investigation approach:** 1. Done: `IssueComment.oldestFirst` is used in all five adapters: `LinearClient.scala:110`, `YouTrackClient.scala:71`, `GitHubClient.scala:414`, `ForgejoClient.scala:181`, `GitLabClient.scala:327`. 2. Done: the order tests per adapter. GitLab (`GitLabClientTest:1199` parse, `:1296` fetch), YouTrack (`YouTrackClientTest:345` fetch), Linear (`LinearClientMockTest:570` fetch across cursor pages), GitHub (`GitHubClientTest:1132` parse only), Forgejo (`ForgejoClientTest:396` parse only). **Fix strategy:** - Decided: the adapters keep the order duty. The recorded IW-610 decision says so (analysis Domain layer, `phase-01-context.md:117`, `phase-02-context.md:273`), and the IW-700 Fix line ("make the comments contract explicit per adapter") agrees. A recorded decision settles this, so this analysis has no CLARIFY marker here. - Rejected: sorting again in `formatComments`. That reverses the recorded decision and adds a second place that owns the order. - Rejected: an opaque "sorted comments" type. It would change five port signatures, five live bindings and the fake to hold a guarantee that five adapter tests already hold. YAGNI. - Make the contract explicit on each `TrackerOps.fetch*IssueComments`. Replace the copied line with Scaladoc for that tracker. It states (a) the API's own order and its source, (b) that the adapter returns `IssueComment.oldestFirst` (ties keep the API order), and (c) what a not-found `Left` means (IW-700 Defect 2 writes that part). The per-tracker order facts: - GitHub: no documented default. `gh issue view --json comments` returned ascending `createdAt` on `cli/cli#13840` (149 comments) and `iterative-works/iw-cli#90`. - GitLab: the documented default is `sort=desc`, `order_by=created_at` (docs.gitlab.com/api/notes, "List project issue notes"). The adapter asks for `sort=asc&order_by=created_at`. - Linear: "By default results are ordered by `createdAt` field" (linear.app/developers/pagination). The direction is not documented. - YouTrack: the order is not documented (devportal `resource-api-issues-issueID-comments`). Only `fields`, `$skip` and `$top` exist. - Forgejo: the endpoint takes only `since` and `before` (code.iterative.works `swagger.v1.json`). Issue 636 returned 6 comments in ascending order. - Add a fetch-level order test to `GitHubClientTest` and `ForgejoClientTest`, with the same name in all five suites: "fetchIssueComments returns comments oldest first when the API answers newest first". Then each adapter's public fetch function, not only its parser, holds the contract. - Change the `formatComments` Scaladoc to say that the caller passes comments oldest first, as `TrackerOps` promises. Keep the "keeps the given order" test, because it pins the decision. - Estimated effort: 1-2 hours. **Risk of fix:** Low. The change is documentation plus two tests. Production code does not change. --- ###### Hypothesis 2: An adapter returns comments that are not sorted today **Evidence against:** All five adapters call `IssueComment.oldestFirst` (see the line references above), and each suite has an order test. **Likelihood:** Low (ruled out by reading the code). **Investigation approach:** 1. Done. The new fetch-level tests from Hypothesis 1 keep it ruled out. **Fix strategy:** None. **Risk of fix:** Not applicable. --- ###### Hypothesis 3: YouTrack paging relies on an order that is not documented **Evidence:** `YouTrackClient.fetchIssueComments` pages with `$skip`, and the YouTrack comments endpoint documents no ordering parameter and no guaranteed order. If the server order is not stable between page requests, a page boundary could drop or repeat a comment. `oldestFirst` cannot fix that. **Likelihood:** Low (nobody has observed it, and no YouTrack instance was available to probe). **Investigation approach:** 1. Fetch a YouTrack issue with more than 100 comments with `$top=100&$skip=0` and `$skip=100` twice, and compare the ids. **Fix strategy:** Out of scope for this issue. The Defect 1 Scaladoc for YouTrack names this assumption. Record it as one line in `FOLLOW-UPS.md`. **Risk of fix:** Not applicable. #### Defect 4: The gh contract probe for the comment shape never runs ##### Reproduction Steps **Environment:** gh authenticated to github.com (this machine: account `mprihoda`), bats. **Steps to reproduce:** 1. `cd /home/mph/Devel/iw/iw-cli-IW-700 && bats --tap -f 'issue view --json returns' test/contract/gh_adapter_contract.bats` 2. Run `probes.sh` (section D4 above). **Expected behavior:** The probe checks `author.login`, `createdAt` and `body` of a real comment. **Actual behavior:** Bats output (exit 0): ``` 1..1 ok 1 gh issue view --json returns the keys iw-cli reads (number,title,state,assignees,body,comments) # skip fixture issue has no comments; the comment shape cannot be checked ``` The skip comes from `gh_adapter_contract.bats:75-77`. The probe shows that the fixture `iterative-works/iw-cli#1` is a merged pull request with `"comments":[]`, in a repository with `"isArchived":true`. **Reproducibility:** Always. ##### Root Cause Hypotheses ###### Hypothesis 1: The fixture has no comments and cannot get any ⭐ Most Likely **Evidence:** - Probe: `#1` has state `MERGED`, `comments: []`. The repository is archived. - GitHub docs (Archiving repositories): in an archived repository "issues, pull requests, … comments and permissions become read-only. To make changes in an archived repository, you must unarchive the repository first." So the first fix that the issue proposes ("add a comment to the fixture issue") is not possible while the mirror is archived. The issue gives a second fix ("point the probe at an issue with comments"), so this is not a question for a human. - `iterative-works/iw-cli#90` is an issue (state `CLOSED`) with 2 comments, each with a string `author.login`, `createdAt` and `body` (probe). Because the repository is archived, the fixture cannot change. **Likelihood:** High (confirmed). **Investigation approach:** 1. Done. **Fix strategy:** - Decided: set `GH_FIXTURE_ISSUE` to `90`. One fixture serves both auth-gated `issue view` probes. A real issue is a better fixture for `gh issue view` than a pull request. Write in the comment that the mirror is archived, so the fixture cannot change. - Replace the skip at `:75-77` with a failure. A frozen fixture with zero comments means that gh changed its output or that the fixture is gone. A silent skip is the defect this issue reports. - Decided: no order assertion in the contract tier. Each adapter sorts, so iw does not depend on the API order (Defect 1). Contract tests pin what iw does depend on. - For parity: add a comment-shape probe to `test/contract/forgejo_api_contract.bats`. It runs anonymously against the public `iterative-works/iw-cli` issue 636 (6 comments; the fields `user.login`, `created_at` and `body` are what `ForgejoClient.parseIssueCommentsResponse` reads). With it, every adapter that has a contract file has a comment probe. GitLab already has one (`glab_adapter_contract.bats:87-114`). Linear and YouTrack have no contract file. - Estimated effort: 0.5-1.5 hours. **Risk of fix:** Low. Contract tests run only nightly and on `contract`-labelled pull requests. --- ###### Hypothesis 2: In CI, the probe skips before it reaches the fixture **Evidence:** The log of the nightly contract job (run on `33042e12`, job 4040, 2026-10-07 03:21 UTC, read through the Forgejo Actions API) shows: ``` ok 7 gh issue view --json returns the keys iw-cli reads (number,title,state,assignees,body) # skip gh not authenticated (set up gh auth or run without --json-shape tests) ok 7 glab issue view --output json returns the keys iw-cli reads (iid,title,state,assignees,description) # skip glab not authenticated ``` `ci.yml:242-244` sets `GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}`. On Forgejo Actions that token comes from Forgejo, so `gh auth status --hostname github.com` fails. That run came before the IW-610 merge, but the auth mechanism has not changed since. **Likelihood:** High (confirmed from the CI log). **Investigation approach:** 1. Done. **Fix strategy:** Outside the issue text. A real github.com token in CI is a secret that a human must provision. Record it as one line in `FOLLOW-UPS.md`. The `ci.yml` comment "so the JSON-shape tests don't skip on the nightly run" is false on this forge. Until that follow-up is done, the Defect 4 fix runs on authenticated developer machines and on `contract`-labelled pull requests only. **Risk of fix:** Not applicable. Split off from #700.

claude referenced this issue

2026-10-11 00:52:13 +00:00

Comment fetch: order, errors and tests differ per adapter #700

claude commented

2026-10-11 04:21:13 +00:00

Intake: agent-ready
Workflow: diagnostic
Reason: all gates passed
Analysis: project-management/issues/IW-783/analysis.md on branch IW-783

Intake: agent-ready Workflow: diagnostic Reason: all gates passed Analysis: project-management/issues/IW-783/analysis.md on branch IW-783

claude added the

agent-ready

label

2026-10-11 04:21:13 +00:00

claude commented

2026-10-15 17:29:57 +00:00

Implement: needs-human
Reason: batch-implement exit 1 — the kanon plugin does not compile against the iw-cli core on current main

kanon/lib/batch/ForgeCatchUp.scala:143 expects Either[String, Option[ForgeState]] from tracker.fetchPullRequestForBranch. Since #778 ("TrackerError on the forge clients and the port's PR/CI/merge calls"), the port returns Either[TrackerError, …]. No phase ran. The branch holds only the issue folder, merged with main at 33e14e5f. Every iw-cli issue fails the same way until the plugin is updated.

[error] /home/mph/.local/share/iw/plugins/kanon/lib/batch/ForgeCatchUp.scala:143:7
[error] Found:    Either[iw.core.model.TrackerError, Option[batch.ForgeState]]
[error] Required: Either[String, Option[batch.ForgeState]]
Compilation failed
EXIT=1

Implement: needs-human Reason: batch-implement exit 1 — the kanon plugin does not compile against the iw-cli core on current main `kanon/lib/batch/ForgeCatchUp.scala:143` expects `Either[String, Option[ForgeState]]` from `tracker.fetchPullRequestForBranch`. Since #778 ("TrackerError on the forge clients and the port's PR/CI/merge calls"), the port returns `Either[TrackerError, …]`. No phase ran. The branch holds only the issue folder, merged with main at 33e14e5f. Every iw-cli issue fails the same way until the plugin is updated. ``` [error] /home/mph/.local/share/iw/plugins/kanon/lib/batch/ForgeCatchUp.scala:143:7 [error] Found: Either[iw.core.model.TrackerError, Option[batch.ForgeState]] [error] Required: Either[String, Option[batch.ForgeState]] Compilation failed EXIT=1 ```

claude added

needs-human

and removed

agent-ready

labels

2026-10-15 17:29:57 +00:00

claude commented

2026-10-16 17:10:44 +00:00

Release: the implement loop failed this issue for a reason outside it. The kanon plugin did not compile against iw-cli main, because the tracker port now returns TrackerError (iw-cli #778). The plugin fix is dev-docs #484, and iw-cli 0.22.1 carries the core change. The issue goes back to the implement loop.

claude added

agent-ready

and removed

needs-human

labels

2026-10-16 17:10:44 +00:00

Sign in to join this conversation.