streamOrExplain misreports why a streamed terminal handover ended, and runStreaming keeps a silent 5-minute default #759

New issue

Open

opened 2026-10-08 03:51:07 +00:00 by claude · 1 comment

claude commented

2026-10-08 03:51:07 +00:00

Member

Found during IW-687 phase 1 (PR #758). All items are in core/adapters/Process.scala, in runStreaming and streamOrExplain.

streamOrExplain cannot identify a tmux client that the time limit stopped — tmux 3.6a catches SIGTERM and exits 1, so killedBySignal (core/adapters/Process.scala:55-56) misses it and the user sees "Failed to switch…"
runStreaming keeps a DefaultTimeoutMs default while streamOrExplain requires the bound — a future direct caller of runStreaming gets the 5-minute bound silently (core/adapters/Process.scala:137)
A signal exit under NoTimeout reports "it ran out of time and was stopped" — with no time limit, a client killed by a signal still takes the time-out wording (core/adapters/Process.scala:177-186)
runStreaming maps a spawn failure to -1 and streamOrExplain then says only "Failed to …" — the cause of an attach that could not start is lost (core/adapters/Process.scala:137-153)

Found during IW-687 phase 1 (PR #758). All items are in `core/adapters/Process.scala`, in `runStreaming` and `streamOrExplain`. - [ ] streamOrExplain cannot identify a tmux client that the time limit stopped — tmux 3.6a catches SIGTERM and exits 1, so `killedBySignal` (`core/adapters/Process.scala:55-56`) misses it and the user sees "Failed to switch…" - [ ] `runStreaming` keeps a `DefaultTimeoutMs` default while `streamOrExplain` requires the bound — a future direct caller of `runStreaming` gets the 5-minute bound silently (`core/adapters/Process.scala:137`) - [ ] A signal exit under `NoTimeout` reports "it ran out of time and was stopped" — with no time limit, a client killed by a signal still takes the time-out wording (`core/adapters/Process.scala:177-186`) - [ ] `runStreaming` maps a spawn failure to -1 and `streamOrExplain` then says only "Failed to …" — the cause of an attach that could not start is lost (`core/adapters/Process.scala:137-153`)

claude referenced this issue

2026-10-08 03:52:41 +00:00

IW-687: An attached session is no longer killed after 5 minutes #760

claude commented

2026-10-15 14:26:13 +00:00

Author

Member

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

1. How do we split IW-759, which has 4 phases, into parts of at most 3 phases? (G5)

The plan has 4 phases, but the runner takes at most 3 phases per issue. The usual answer is to split the issue, not to raise the limit. Phases 2, 3 and 4 make a chain: phase 2 adds a new result type (StreamOutcome), and phases 3 and 4 each add one case to it. Phase 1 does not depend on the others (tasks.md, analysis.md).

Defects 1, 3 and 4 each add one case to StreamOutcome. Defect 2 is independent.

a) IW-759 keeps phases 2-4 (4.5-7.5h). Phase 1 becomes a new issue (0.5-1h). The chain stays in one issue, and the API docs are generated again only once for it. Both parts change the signature of runStreaming, so the part that merges second must rebase.
b) IW-759 keeps phases 1-3. Phase 4 (failure to start) becomes a new issue that starts after IW-759 merges. The order stays as planned. Phase 4 must wait, and it generates Process.md again.
c) Run all 4 phases as one issue. This raises the 3-phase limit for this issue.

Recommended: a) The chain that shares the new type stays together, and the part that we remove is small and does not depend on the chain.

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-759/analysis.md on branch IW-759 ### 1. How do we split IW-759, which has 4 phases, into parts of at most 3 phases? (G5) The plan has 4 phases, but the runner takes at most 3 phases per issue. The usual answer is to split the issue, not to raise the limit. Phases 2, 3 and 4 make a chain: phase 2 adds a new result type (`StreamOutcome`), and phases 3 and 4 each add one case to it. Phase 1 does not depend on the others ([tasks.md](https://code.iterative.works/iterative-works/iw-cli/src/branch/IW-759/project-management/issues/IW-759/tasks.md#L9-L14), [analysis.md](https://code.iterative.works/iterative-works/iw-cli/src/branch/IW-759/project-management/issues/IW-759/analysis.md#L491-L491)). > Defects 1, 3 and 4 each add one case to `StreamOutcome`. Defect 2 is independent. - **a) IW-759 keeps phases 2-4 (4.5-7.5h). Phase 1 becomes a new issue (0.5-1h).** The chain stays in one issue, and the API docs are generated again only once for it. Both parts change the signature of `runStreaming`, so the part that merges second must rebase. - **b) IW-759 keeps phases 1-3. Phase 4 (failure to start) becomes a new issue that starts after IW-759 merges.** The order stays as planned. Phase 4 must wait, and it generates `Process.md` again. - **c) Run all 4 phases as one issue.** This raises the 3-phase limit for this issue. **Recommended: a)** The chain that shares the new type stays together, and the part that we remove is small and does not depend on the chain. 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 14:26:13 +00:00