You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "me2seeks (via GitHub)" <gi...@apache.org> on 2026/08/21 07:07:33 UTC

[I] fix(cli): a second TUI attached to a Session with a running Turn is trapped — every exit path aborts the Turn [maka]

me2seeks opened a new issue, #3380:
URL: https://github.com/apache/maka/issues/3380

   ### Problem
   
   Two SSH sessions on the same machine:
   
   1. SSH session A runs `maka tui` and starts a long-running task (a Turn is in flight).
   2. SSH session B opens a second `maka tui` and — via the session picker or `/resume` — switches to the Session that is busy in A.
   3. TUI B attaches to the in-flight Turn (`switchSession` returns `activeTurn`; the runner starts an `attached` turn view, so `turnRunning = true`).
   
   From that moment TUI B is **trapped**, and every way out is destructive:
   
   - `/session` (and any other known slash command except `/goal` and `/recap`, per #3310) is intercepted: `Cannot run /session while a turn is running — interrupt it (Esc) or wait for it to finish.` — so you cannot switch away.
   - Following that hint (double `Esc`) or pressing `Ctrl+C` mid-turn calls `requestTurnInterrupt()` → `driver.stop()` → host `turn.stop` RPC, which **aborts the shared long task for both clients**.
   - Even *quitting* TUI B is destructive: `exit` mid-turn / double `Ctrl+C` / `SIGINT` / `SIGHUP` all reach `beginClose()`, which calls `driver.stop()` when no interrupt is in flight — killing the Turn that TUI A is watching.
   
   The only non-destructive escape is `kill -9` of the TUI B process.
   
   ### Root cause (code-confirmed, `packages/cli/src`)
   
   - `runtime-host-session-driver.ts` `switchSession` (L436+) intentionally attaches to a Session with a live Turn and hands back `activeTurn` — multi-client reattach is a supported pattern, so attaching is not the bug.
   - `pi-tui-runner.ts` `editor.onSubmit` (L1099–L1116) refuses every known slash command while `turnRunning`, including `/session` — the one command that would let the second TUI leave.
   - `pi-tui-runner.ts` mid-turn `Ctrl+C` (L3055) / double `Esc` (L3063) → `requestTurnInterrupt` (L779) → `input.driver.stop()` (L798); `runtime-host-session-driver.ts` `stop()` (L619) issues `turn.stop` for the Session's root Turn **regardless of which client started it**.
   - `pi-tui-runner.ts` `beginClose` (L695) also calls `driver.stop()` on quit, so there is no detach-only close path.
   
   ### Proposed direction: let `/session` switch away mid-turn (detach, not interrupt)
   
   An attach mutex/lease was considered and rejected: multi-client attach is a designed Runtime Host capability (turns started by another client or the Host are meant to be observable), and leases bring stale-lock/heartbeat complexity.
   
   Instead, extend the #3310 pattern — which let `/goal` and `/recap` run mid-turn because they are independent of the running turn — to `/session`:
   
   - Switching away is **turn-independent**: in Runtime Host mode the Turn is host-driven, so the TUI is only a view. Detaching the view does not touch the Turn.
   - Mechanically feasible today: `driver.switchSession` requires no idle state, and `#replaceChannel` → `channel.close()` finishes every per-turn event queue (`runtime-host-session-channel.ts` L276), which ends the attached turn's drain loop in `runAgentTurn` and resets `busy`/`turnRunning` cleanly.
   - The Turn (and any host-driven Goal continuation) keeps running; switching back later re-attaches via the existing `activeTurn` path.
   
   Implementation notes / scope:
   
   1. Exempt `session` from the mid-turn interception in `editor.onSubmit`; open the picker while `turnRunning`.
   2. On selection, run the switch **without** `driver.stop()`; add a runner-side generation fence so late events from the abandoned turn cannot render into the new Session's transcript.
   3. Minimal scope: allow switch-away only when the running turn is an *attached* (externally started) turn — the reported trap. Allowing it for self-started turns (queued-followup/fallback flush, `interruptRequested` state) can be a follow-up.
   4. Follow-up worth its own issue: interrupt/close semantics for foreign turns — `Ctrl+C`, `Esc`, and `beginClose` currently kill a Turn this TUI did not start; consider ownership-aware interrupt or an explicit "detach" affordance.
   
   Related: #3310 (mid-turn slash-command interception), #3347 (config changes mid-turn, desktop).
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org


Re: [I] fix(cli): a second TUI attached to a Session with a running Turn is trapped — every exit path aborts the Turn [maka]

Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han closed issue #3380: fix(cli): a second TUI attached to a Session with a running Turn is trapped — every exit path aborts the Turn
URL: https://github.com/apache/maka/issues/3380


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org


Re: [I] fix(cli): a second TUI attached to a Session with a running Turn is trapped — every exit path aborts the Turn [maka]

Posted by "me2seeks (via GitHub)" <gi...@apache.org>.
me2seeks commented on issue #3380:
URL: https://github.com/apache/maka/issues/3380#issuecomment-5366390037

   I'm working on this issue.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org