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

New issue

claude · 2026-10-03T19:32:51Z

claude commented

2026-10-03 19:32:51 +00:00

Found in IW-610 (review-phase-02-20261003-055441.md, architecture, error-handling, testing).

formatComments prints 'oldest first' but keeps the adapter's order; no core sort or per-adapter contract test pins the order — core/output/IssueFormatter.scala:54
On GitLab a 404 from the comments fetch prints 'issue not found' after the issue fetch succeeded, because explainGitLabError serves both fetches — core/commands/Issue.scala
The harness tests the comment-fetch failure only for Linear and GitLab — core/test/IssueHarnessTest.scala
The gh contract fixture issue iterative-works/iw-cli#1 has no comments, so the comments element-shape probe in test/contract/gh_adapter_contract.bats never runs — add a comment to the fixture issue or point the probe at an issue with comments

Fix: make the comments contract explicit per adapter (order, not-found meaning) and test it for every adapter.

Found in IW-610 (review-phase-02-20261003-055441.md, architecture, error-handling, testing). - formatComments prints 'oldest first' but keeps the adapter's order; no core sort or per-adapter contract test pins the order — core/output/IssueFormatter.scala:54 - On GitLab a 404 from the comments fetch prints 'issue not found' after the issue fetch succeeded, because explainGitLabError serves both fetches — core/commands/Issue.scala - The harness tests the comment-fetch failure only for Linear and GitLab — core/test/IssueHarnessTest.scala - The gh contract fixture issue iterative-works/iw-cli#1 has no comments, so the comments element-shape probe in test/contract/gh_adapter_contract.bats never runs — add a comment to the fixture issue or point the probe at an issue with comments Fix: make the comments contract explicit per adapter (order, not-found meaning) and test it for every adapter.

mph referenced this issue from a commit

2026-10-06 12:49:52 +00:00

workflow: Triage lessons for IW-610

claude referenced this issue

2026-10-06 23:15:39 +00:00

IW-610: iw issue reports and prints an issue's comments #728

claude commented

2026-10-08 01:39:05 +00:00

Intake: needs-input
Workflow: diagnostic
Reason: G5 (4 phases)
Analysis: project-management/issues/IW-700/analysis.md on branch IW-700

1. How should IW-700 be split into parts of at most 3 phases each? (G5)

The plan for this issue has 4 phases, about 4.5-8.5h in total (tasks.md). A run takes at most 3 phases, so the usual answer is to split the issue, not to raise that limit. Phase 2 must come after Phase 1, because its GitLab tests use the new message that Phase 1 adds. Phases 3 and 4 do not depend on any other phase. A review note says that IW-700 changes the same code as IW-672 (open PR #735) and IW-749, so all parts should land after those two.

a) Two parts: Phases 1+2, then Phases 3+4. Part one fixes the wrong GitLab "issue not found" message and adds the failed-comment-fetch tests for every tracker. Part two writes down the oldest-first comment order for each tracker, adds order tests for GitHub and Forgejo, and makes the gh and Forgejo contract probes run. Each part is about 3-4.5h and stands on its own.
b) Two parts: Phases 1+2+3, then Phase 4. This keeps all the core code changes together. The second part is a small part of about 1h that changes only the contract tests.
c) Run all 4 phases as one issue. This raises the 3-phase limit for this issue.

Recommended: a) — The two parts are about the same size, the one dependency (Phase 2 on Phase 1) stays in one part, and each part is a clear topic: error messages, then the order and probe contract.

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: diagnostic Reason: G5 (4 phases) Analysis: project-management/issues/IW-700/analysis.md on branch IW-700 ### 1. How should IW-700 be split into parts of at most 3 phases each? (G5) The plan for this issue has 4 phases, about 4.5-8.5h in total ([tasks.md](https://code.iterative.works/iterative-works/iw-cli/src/branch/IW-700/project-management/issues/IW-700/tasks.md#L10-L13)). A run takes at most 3 phases, so the usual answer is to split the issue, not to raise that limit. Phase 2 must come after Phase 1, because its GitLab tests use the new message that Phase 1 adds. Phases 3 and 4 do not depend on any other phase. A review note says that IW-700 changes the same code as IW-672 (open PR #735) and IW-749, so all parts should land after those two. - **a) Two parts: Phases 1+2, then Phases 3+4.** Part one fixes the wrong GitLab "issue not found" message and adds the failed-comment-fetch tests for every tracker. Part two writes down the oldest-first comment order for each tracker, adds order tests for GitHub and Forgejo, and makes the gh and Forgejo contract probes run. Each part is about 3-4.5h and stands on its own. - **b) Two parts: Phases 1+2+3, then Phase 4.** This keeps all the core code changes together. The second part is a small part of about 1h that changes only the contract tests. - **c) Run all 4 phases as one issue.** This raises the 3-phase limit for this issue. **Recommended: a)** — The two parts are about the same size, the one dependency (Phase 2 on Phase 1) stays in one part, and each part is a clear topic: error messages, then the order and probe contract. 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-08 01:39:06 +00:00

mph commented

2026-10-10 19:14:33 +00:00

1: a

claude referenced this issue

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

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

claude commented

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

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

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

claude added

agent-ready

and removed

needs-input

labels

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

claude commented

2026-10-15 14:51:16 +00:00

Implement: needs-human
Reason: batch-implement exit 1 — the kanon plugin command did not compile against the iw-cli core of this branch, so no phase ran

ForgeCatchUp.scala in the kanon plugin expects fetchPullRequestForBranch to return Either[String, …]. After the merge of main (83fa37ff), core returns Either[TrackerError, …] (core changes #778–#780). No batch-implement.log was written. The issue itself is not the cause: the plugin must be updated to TrackerError before the loop can run any iw-cli issue. When the plugin is fixed, release this issue to agent-ready again.

Command output (last lines):

[warn]  Using directives detected in multiple files:
- /home/mph/.local/share/iw/plugins/kanon/lib/deps.scala:1:1-7:41
It is recommended to keep them centralized in the /home/mph/Devel/iw/iw-cli-IW-700/core/project.scala file.

[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

Implement: needs-human Reason: batch-implement exit 1 — the kanon plugin command did not compile against the iw-cli core of this branch, so no phase ran `ForgeCatchUp.scala` in the kanon plugin expects `fetchPullRequestForBranch` to return `Either[String, …]`. After the merge of `main` (83fa37ff), core returns `Either[TrackerError, …]` (core changes #778–#780). No `batch-implement.log` was written. The issue itself is not the cause: the plugin must be updated to `TrackerError` before the loop can run any iw-cli issue. When the plugin is fixed, release this issue to `agent-ready` again. Command output (last lines): ``` [warn] Using directives detected in multiple files: - /home/mph/.local/share/iw/plugins/kanon/lib/deps.scala:1:1-7:41 It is recommended to keep them centralized in the /home/mph/Devel/iw/iw-cli-IW-700/core/project.scala file. [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 ```

claude added

needs-human

and removed

agent-ready

labels

2026-10-15 14:51:16 +00:00

claude commented

2026-10-16 17:10:40 +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:40 +00:00

Sign in to join this conversation.