fix(gui): preserve Stop button when returning to a running session - #630
Open
niranjannie wants to merge 1 commit into
Open
Conversation
When a user switched away from a running conversation and back, the Stop button disappeared (replaced by Send) even though the backend turn was still executing. Sending a new message in that conversation then failed with "This session is already running a turn. Wait for it to finish or stop it." — leaving the user no way to interrupt the turn from the UI. Root cause: `selectSession` eagerly set `running` to false before the new session's `ready` event had arrived, briefly hiding the Stop button. The `case "ready"` handler already restores `d.running` correctly (owner catch 2026-08-24, recorded at the same site), so the eager reset is both unnecessary and harmful on mid-turn reconnects. Remove the eager `setRunning(false)` in `selectSession` and let the `ready` event establish the truth. The other state resets in `selectSession` are unchanged: `todo`, `streaming`, `agent`, and the workspace/branch/folder flags are not affected. Fixes andrewyng#506
Author
|
cc @cagdasyurekli — thanks for the early review on the issue thread. This is my first contribution to OpenWorker. The fix removes the eager I did not add an App.tsx-level test because no App.tsx test harness exists in the repo. Adding one felt like scope creep for a 1-line change. Happy to follow up with a harness in a separate PR if useful. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When a user switches away from a conversation whose turn is still running and then switches back, the Stop button disappears (replaced by Send) — even though the backend turn is still executing. The user is left with no UI control to interrupt the running turn; sending a new message fails with
This session is already running a turn. Wait for it to finish or stop it.Root cause
selectSessioninsurfaces/gui/src/App.tsxeagerly calledsetRunning(false)before the new session'sreadyevent had arrived. Thecase "ready"handler at the same site already restoresd.runningcorrectly (this was fixed previously for the reconnect-mid-turn case on 2026-08-24, recorded at the same site). The eagersetRunning(false)raced with that restore and left the UI in the wrong state for any user who returned to a running session.Fix
Remove the eager
setRunning(false)inselectSession. The other state resets inselectSessionare unchanged (todo,streaming,agent, workspace/branch/folder flags).Why not just gate the reset?
A guarded reset (e.g.
if (running) setRunning(false)) would still race with thereadyevent for sessions that are truly idle — thereadyevent arrives after the click and would overwrite correctly, but for any case wherereadyis delayed or lost, the gate would still incorrectly clearrunning. The cleanest, smallest fix is to delegate toreadyentirely, matching the established pattern for initial session load.Out of scope
readyevent handler at the same site, which already covers the truth source.Fixes #506