You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Flaky: Fish can lose keys typed right after a handed-over read returns #356
Known pre-existing race (reproduced on release/v0.18.0): under parallel load, keys typed within about a second after Fish returns from a handed-over read to its prompt can be lost. Live tests pause before the next command; see docs/development/fish-typeahead.md. Tracked so it is not mistaken for a regression in queue or input-awareness work.
Confirmed Linux/Fish findings and stabilization work:
Published queue head 7fb6b5ac23aeecc21e7a0d7ba5b824af95f505aa reproduces both read-handover and typing-after-read failures on Ubuntu 24.04 arm64, Fish 3.7.0, Node 26.10.0. Original amd64 CI evidence: run 38071796100; descendant evidence: run 38071808042.
Fish 3.7 deliberately does not enable bracketed paste in builtin read. The frontend previously depended on input-mode output for terminal handover. Answers stayed in the composer/queue while the native reader waited. answersByDefault is not the cause and was not weakened.
The fix uses Fish's real fish_read event to emit an authenticated private reader marker before its prompt. Terminal ownership survives detach/reattach and ends at the shell prompt. Wrong-token markers stay ordinary output; hidden answers are neither drawn nor recorded as commands.
Separate Fish 3.7 failure: multiline composer/queue submissions now use begin/end. POSIX shells retain brace groups. Composer, dispatcher and paste parse checks must use the actual shell ID.
Separate fixture errors: the Ctrl+C survivor waits for its installed trap and uses Bash's supported timed read, with a release file instead of a fixed sleep; typing-after-read waits for a unique runtime-built prompt rather than a historical redraw.
Commits on fix/workflow-fish-routing: f0db588 reader fix; dfb242f native grouping and fixtures; eaeb281 non-destructive merge of the upstream #348 checkpoint (684a3fb on fix/workflow-input-checkpoint). These are local candidates pending canonical verification of the propagated heads and GitHub CI.
Verification completed:
npm run typecheck.
Canonical npm run verify on the queue candidate (explicit TERM=xterm-256color COLORTERM=truecolor, inherited NO_COLOR unset): passed, including full suite, cleanup and diff check. Explicit NO_COLOR tests remain enabled.
Three new zsh/Bash/Fish multiline queue PTY tests: passed on macOS.
Ubuntu fixed snapshot: all tests in inputAwarenessLive.test.ts, typingAfterRead.test.ts, queryOrder.test.ts, commandQueueLive.test.ts passed, including the new multiline cases, hidden-reader detach/reattach, interrupts, failure pauses and narrow/NO_COLOR/Safe presentation.
The first full local run was invalidated by inherited color-disable/dumb-terminal settings and ENOSPC. It is retained as a failed run, not counted as success.
No physical terminal QA has occurred. Published PR heads are not yet updated; there is no shared-file freeze or permission to merge to master/release. Exact final heads and Actions results will follow in #359.
Stabilization follow-up; final publication/CI remains pending.
The authenticated Fish reader handover is retained. No change weakens answersByDefault. Subsequent regressions cover hidden function readers, an interrupted foreground job, native Fish multiline grouping, and detach/reattach during a hidden read. The attach privacy correction protects raw input before probing/journal I/O and excludes running/startup input from optional key diagnostics.
The macOS canonical suite passed at input candidate 9465eb5. Portable fixture-only follow-up 86fb4e4 passed focused mise/provider checks; a fresh exact-head canonical run is underway.
The latest full Ubuntu 24.04 arm64 / Fish 3.7.0 / Node 26.10 run at workflow 5756f7c failed:
Report assertion expected the old unquoted Markdown status. ee5483e updates that assertion without weakening literal formatting or review.
Pager and detach fixtures invoked less/vim, absent in our minimal disposable VM. Both prerequisites are now installed there.
Immediate same-size mise edits retained identical mtime/ctime even at nanosecond precision. 86fb4e4 makes its stat-based invalidation test change the timestamp explicitly and documents the unchanged-metadata refresh limitation.
The provider test assumed host Homebrew; 86fb4e4 supplies its own executable availability fixture. No installer is executed.
The existing history timing threshold failed at p95 62.1ms; it passed an isolated rerun with the same threshold. Final canonical verification remains required.
A new full Ubuntu run uses exact workflow 5e45e87. These are local additive candidates, not yet advertised as green published heads. Physical terminal QA is still outstanding. Main/release and the independent native/workspace branches remain untouched.
v0.21 stabilization: not reproducible with the current code. tests/typingAfterRead.test.ts (keys typed the moment a Fish read finishes) passed 40/40 on macOS (Fish 4.9.3) under 8× parallel load, and 22/22 Linux runs (Debian container, Fish 3.6, Node 26.12) under 2× load that got past startup. The other 2 Linux runs stalled before the frontend drew anything (VM I/O, one process in uninterruptible disk sleep), not in the input path. The earlier fixes hold: editor queries answered in the same turn, input held behind answers (QueryOrder), and the fish_read reader handover. Type-ahead during a Fish read stays subject to Fish's own editor-start query wait, as documented in docs/development/fish-typeahead.md. Leaving this open for the maintainer's decision; details in #423.
v0.22 check (#431): still not reproduced; not declared fixed. Left open and deferred for the maintainer.
tests/typingAfterRead.test.ts → live fish: keys typed the moment a read finishes are never lost, on the #433 branch (deva8b383c2 plus the #426 input-ownership change, which holds keys until the session's look answers), macOS 27 arm64, Fish 4.9.3, Node 26.10:
8 copies in parallel, four rounds: 32/32 passed (each run types an answer and the next command at once after six reads: 192 sequences, no key lost).
An accidental 16-copy run failed in all 16 copies at startup (timed out waiting for completed journal for echo READY) before any read ran: sandbox journaling stalled on the external scratch disk. It says nothing about this issue and is not counted.
Together with v0.21's 40/40 (macOS, 8×) and 22/22 (Linux Fish 3.6), the current defenses hold: editor queries answered in the same turn, input held behind answers (QueryOrder), and the fish_read reader handover. Type-ahead during a Fish read remains subject to Fish's own editor-start query wait (docs/development/fish-typeahead.md).
Reassessed for v0.22 (candidate fa7ec665): still relevant as documented, still not reproduced; stays deferred.
No change touches Fish's handling of keys typed during its own read. The v0.22 Fish work is #449: NMSh's markers on Fish 3 are written through cat, so they're no longer lost to an interrupted write. That removes one way NMSh could misjudge who owns the terminal after a read returns, but it isn't this issue.
typingAfterRead (Fish included) passes locally on Fish 4.9.3 and on CI's Ubuntu Fish 3.7.0. The physical Fish passes B9/B10 were not run in v0.22 QA, so there's no new physical evidence either way.
Reassessed with #457 (e8dd44e4). Keys typed after Fish's read returned, before the prompt is back, are no longer read by Fish as the next command. The prompt hook takes them back from the terminal, and they wait for approval: never lost, never run by themselves. CI's Ubuntu Fish 3.7 loop ran the Fish typing tests 20/20. Typing during a Fish read is unchanged (Fish's own editor queries). Still not reproduced; left open for the maintainer.
Activity
raiseCatError commentedon Oct 11, 2026
Confirmed Linux/Fish findings and stabilization work:
7fb6b5ac23aeecc21e7a0d7ba5b824af95f505aareproduces both read-handover and typing-after-read failures on Ubuntu 24.04 arm64, Fish 3.7.0, Node 26.10.0. Original amd64 CI evidence: run 38071796100; descendant evidence: run 38071808042.read. The frontend previously depended on input-mode output for terminal handover. Answers stayed in the composer/queue while the native reader waited.answersByDefaultis not the cause and was not weakened.fish_readevent to emit an authenticated privatereadermarker before its prompt. Terminal ownership survives detach/reattach and ends at the shell prompt. Wrong-token markers stay ordinary output; hidden answers are neither drawn nor recorded as commands.begin/end. POSIX shells retain brace groups. Composer, dispatcher and paste parse checks must use the actual shell ID.Commits on
fix/workflow-fish-routing:f0db588reader fix;dfb242fnative grouping and fixtures;eaeb281non-destructive merge of the upstream #348 checkpoint (684a3fbonfix/workflow-input-checkpoint). These are local candidates pending canonical verification of the propagated heads and GitHub CI.Verification completed:
npm run typecheck.npm run verifyon the queue candidate (explicitTERM=xterm-256color COLORTERM=truecolor, inherited NO_COLOR unset): passed, including full suite, cleanup and diff check. Explicit NO_COLOR tests remain enabled.inputAwarenessLive.test.ts,typingAfterRead.test.ts,queryOrder.test.ts,commandQueueLive.test.tspassed, including the new multiline cases, hidden-reader detach/reattach, interrupts, failure pauses and narrow/NO_COLOR/Safe presentation.No physical terminal QA has occurred. Published PR heads are not yet updated; there is no shared-file freeze or permission to merge to master/release. Exact final heads and Actions results will follow in #359.
raiseCatError commentedon Oct 11, 2026
Stabilization follow-up; final publication/CI remains pending.
The authenticated Fish reader handover is retained. No change weakens answersByDefault. Subsequent regressions cover hidden function readers, an interrupted foreground job, native Fish multiline grouping, and detach/reattach during a hidden read. The attach privacy correction protects raw input before probing/journal I/O and excludes running/startup input from optional key diagnostics.
The macOS canonical suite passed at input candidate 9465eb5. Portable fixture-only follow-up 86fb4e4 passed focused mise/provider checks; a fresh exact-head canonical run is underway.
The latest full Ubuntu 24.04 arm64 / Fish 3.7.0 / Node 26.10 run at workflow 5756f7c failed:
A new full Ubuntu run uses exact workflow 5e45e87. These are local additive candidates, not yet advertised as green published heads. Physical terminal QA is still outstanding. Main/release and the independent native/workspace branches remain untouched.
raiseCatError commentedon Oct 18, 2026
v0.21 stabilization: not reproducible with the current code.
tests/typingAfterRead.test.ts(keys typed the moment a Fish read finishes) passed 40/40 on macOS (Fish 4.9.3) under 8× parallel load, and 22/22 Linux runs (Debian container, Fish 3.6, Node 26.12) under 2× load that got past startup. The other 2 Linux runs stalled before the frontend drew anything (VM I/O, one process in uninterruptible disk sleep), not in the input path. The earlier fixes hold: editor queries answered in the same turn, input held behind answers (QueryOrder), and thefish_readreader handover. Type-ahead during a Fish read stays subject to Fish's own editor-start query wait, as documented in docs/development/fish-typeahead.md. Leaving this open for the maintainer's decision; details in #423.raiseCatError commentedon Oct 18, 2026
v0.22 check (#431): still not reproduced; not declared fixed. Left open and deferred for the maintainer.
tests/typingAfterRead.test.ts→live fish: keys typed the moment a read finishes are never lost, on the #433 branch (deva8b383c2plus the #426 input-ownership change, which holds keys until the session's look answers), macOS 27 arm64, Fish 4.9.3, Node 26.10:timed out waiting for completed journal for echo READY) before anyreadran: sandbox journaling stalled on the external scratch disk. It says nothing about this issue and is not counted.Together with v0.21's 40/40 (macOS, 8×) and 22/22 (Linux Fish 3.6), the current defenses hold: editor queries answered in the same turn, input held behind answers (
QueryOrder), and thefish_readreader handover. Type-ahead during a Fish read remains subject to Fish's own editor-start query wait (docs/development/fish-typeahead.md).v0.22 ledger: #356 not reproduced under 8x load
raiseCatError commentedon Oct 19, 2026
Reassessed for v0.22 (candidate
fa7ec665): still relevant as documented, still not reproduced; stays deferred.No change touches Fish's handling of keys typed during its own
read. The v0.22 Fish work is #449: NMSh's markers on Fish 3 are written throughcat, so they're no longer lost to an interrupted write. That removes one way NMSh could misjudge who owns the terminal after areadreturns, but it isn't this issue.typingAfterRead(Fish included) passes locally on Fish 4.9.3 and on CI's Ubuntu Fish 3.7.0. The physical Fish passes B9/B10 were not run in v0.22 QA, so there's no new physical evidence either way.raiseCatError commentedon Oct 19, 2026
Reassessed with #457 (
e8dd44e4). Keys typed after Fish'sreadreturned, before the prompt is back, are no longer read by Fish as the next command. The prompt hook takes them back from the terminal, and they wait for approval: never lost, never run by themselves. CI's Ubuntu Fish 3.7 loop ran the Fish typing tests 20/20. Typing during a Fishreadis unchanged (Fish's own editor queries). Still not reproduced; left open for the maintainer.