fix(tui): close busy-flag race that stuck queue-mode back-to-back sends - #56100
Merged
Conversation
Under display.busy_input_mode: queue, sending two messages back-to-back
hung the session on 'Analyzing…' until a manual Ctrl+C.
The submit path only marked the session busy inside the .then of an
async input.detect_drop RPC. dispatchSubmission routes queue-vs-send on
getUiState().busy, so a second Enter inside that RPC window read
busy===false and raced a second prompt.submit down the send path
instead of enqueuing locally. The gateway accepts the mid-turn submit
as a success ({status:'queued'}, not an error), and the client's only
re-queue recovery is gated on catching a 'session busy' error — which
never fires — so the message became invisible to the client-side drain
effect and the UI stayed busy forever.
Extract the ready-prompt submit into a pure submissionCore module and
mark the session busy synchronously at the choke point, before the
detect_drop round-trip, closing the gap for every caller (mainline
submit, queue-edit picks, drain, interpolation). Verified the real
gateway already queues+drains both turns correctly, so the fix is
purely client-side. Adds submissionCore.test.ts whose regression
assertions fail without the synchronous busy and pass with it.
alt-glitch
added
type/bug
Collaborator
Related: salvage of #56046 (@benbarclay's original, still open) onto current |
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
3 participants
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
Closes the queue-mode busy-flag race that stuck the TUI on "Analyzing…" forever after two rapid back-to-back sends. Salvage of #56046 by @benbarclay onto current
main.Root cause: the submit path set the session
busyflag asynchronously, only inside the.thenof aninput.detect_dropRPC.dispatchSubmissionroutes queue-vs-send ongetUiState().busy, so a second Enter pressed inside that RPC window readbusy === falseand raced a secondprompt.submitdown the send path. The gateway accepts a mid-turn submit as a success ({status:"queued"}, not an error), so the client'sisSessionBusyErrorre-queue path never fired and the message vanished from the local drain effect — UI stuck busy until Ctrl+C.Changes
ui-tui/src/app/submissionCore.ts(new): pure, testable submit core;markSubmitting()flips busy synchronously at the choke point, before thedetect_dropround-trip. LegacyisSessionBusyErrorre-queue kept as a defensive net.ui-tui/src/app/useSubmission.ts:sendnow funnels throughsubmitPrompt; dead imports removed.ui-tui/src/__tests__/submissionCore.test.ts(new): asserts busy flips synchronously before the RPC resolves.Validation
false(races a 2nd submit)true(local enqueue)markSubmitting()Infographic