[baldurpan]

Closes #176

What changed

The 15s AbortSignal.timeout passed to fetch also bounds reading the body. Linear, GitHub and Jira translated a TimeoutError only at the fetch call, so a body that stalled after the headers missed TIMEOUT_MESSAGE and came out with code failed. It now reports <what> did not answer within 15s, as ClickUp has since #175.

• Linear: readBody rethrows a timeout through a shared timeoutError. A real parse failure still returns undefined.
• GitHub and Jira: every body read goes through readGitHubBody or readJiraBody, and a non-timeout read error is rethrown unchanged.
• Wider than the issue: it also covers .text() on non-OK responses (githubFailure, fetchJiraIssue, jiraAssignFailure), and the assign reads. These had the same defect.
• Release note: .changeset/stalled-body-timeout.md, patch, level confirmed by the maintainer.

Verification

Gate 1 was run on top of #204, which fixed the main failures in #203. pnpm check, pnpm typecheck, pnpm --filter docs typecheck, pnpm build, pnpm test (2094 passed), pnpm docs:test (69 passed) and the test-markers check all exited 0. pnpm check was re-run after the note was added.

• Mutation checks: forcing isTimeout to true fails exactly the 2 new parse-failure tests. Removing the body-read guards fails 9 stalled-body tests across all three integrations.
• Real server: the built fetchGitHubLogin against a local server that sends headers and half a body, then stalls, gives GitHub: /user did not answer within 15s. for both a 200 and a 500. Linear and Jira are covered by mocks only.

Review

The reviewer subagent returned FAIL on the first pass (no release note; parse failure unpinned for GitHub and Jira), then PASS WITH NOTES once both were fixed.

Non-blocking behaviour worth reading:

• Pull-request head branch lookup: fetchGitHubPullRequestHeadBranch keeps its catch-all, so a stalled body there gives no suggested branch rather than a timeout. The lookup only improves a refusal message, and a stalled fetch there was already swallowed the same way. That makes the guard at that read a no-op.
• Linear non-OK answers: readBody runs before the status check, so a 429 or other non-OK answer whose body stalls now reports a timeout rather than the rate-limit or failed message. No test pins this.
• Assign paths: branch records assignment failures as warnings, so a stalled assign body gets the new message but no timeout code. The note's --json claim holds for reads that abort the command.

Smaller test gaps from the review: the /myself read in Jira assign, some path arguments to the failure helpers, { cause }, and token absence in the new tests have no assertion of their own.

[baldurs-reviewer]

code-reviewer: minor issues

The change wraps every response-body read in the Linear, GitHub and Jira clients so that a TimeoutError raised while reading the body becomes the same did not answer within 15s error as a stalled fetch. Genuine parse failures are still passed through unchanged. The implementation is correct and consistent across the three clients, and the tests pin both the timeout and non-timeout paths for each. I found only two small points: one Linear test sits in the wrong describe, and the changeset's --json claim reaches further than the code does.

---

Reviewed 9be4e40 for baldurpan · claude-opus-5-5 · 7 files · $0.56

[baldurs-reviewer]

code-reviewer follow-up: looks good

Since the last review, the Linear stalled-body test has moved into the fetchLinearIssue block, two startLinearIssue stalled-body cases (read and move) have been added, and the release note now limits its --json claim. Both earlier comments are addressed and nothing new turned up in these changes.

Earlier comments

• Fixed; yours to resolve: Suggestion: fetchLinearIssue stall test sits in startLinearIssue's failures block, without that block's project-file stub
• Fixed; yours to resolve: Suggestion: Release note's --json claim does not hold for assign/start paths

---

Reviewed 00f74c7 (changes since 9be4e40) for baldurpan · claude-opus-5-5 · 2 files · $0.14