Signal Terminal end-of-input at stdin EOF instead of hanging - #6676
Merged
tim-smart merged 4 commits intoJul 28, 2026
Conversation
🦋 Changeset detectedLatest commit: d0d11de The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughNodeTerminal tracks stdin EOF, closes its input queue when stdin ends, and causes ChangesNode terminal EOF handling
Estimated code review effort: 3 (Moderate) | ~20 minutes 🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Address review polish on the stdin EOF fix: - Reduce the changeset to a single-line summary instead of a paragraph restating the implementation. - Drop the `=== true` coercion on `stdin.readableEnded`; both uses are boolean contexts, so it never changed the result. - Collapse the `readInput` end-of-input comment to the reason it exists (consumers would hang) rather than narrating what the handler does. Comments explaining the Bun `readableEnded` gap and why `readLine` listens to readline "close" instead of stdin "end" are kept, since neither is evident from the code.
tim-smart
enabled auto-merge (squash)
July 28, 2026 02:14
Contributor
Bundle Size Analysis
|
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
2 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.
Closes #4895
Problem
NodeTerminalnever observes stdin end-of-input:readInputends itsQueue<UserInput, Cause.Done>only whenshouldQuitmatches a Ctrl+C/Ctrl+D keypress. With piped or closed stdin (echo y | my-cli login), any prompt after the buffered keypresses are consumed blocks onQueue.takeforever — even thoughPrompt.runalready maps queue end toQuitErrorand documents that it fails "if terminal input ends".readLineonly listens for the readline"line"event, so it hangs the same way at EOF (the original report in Terminal.readLine hangs when input stream is closed #4895).Fix
maketracks end-of-input once per terminal (stdin"end"fires once per process, and Bun never setsreadableEnded, so readers created after the event cannot re-detect it from the stream).readInputends its queue on stdin"end"(or immediately when input already ended). Keypresses buffered before the end still deliver first;Prompt.runthen fails withTerminal.QuitErrorthrough the existingCause.Donemapping.readLinefails withTerminal.QuitErrorwhen the readline interface closes. Listening to readline"close"rather than stdin"end"preserves the existing behavior where a final line without a trailing newline still flushes through"line"first.Interactive TTY sessions are unaffected: a TTY stdin does not emit
"end"during normal use, and Ctrl+C/Ctrl+D in raw mode remain keypresses handled byshouldQuit.BunTerminalreuses this implementation, so both runtimes are covered.Verification
Verified end-to-end in a downstream CLI (Bun runtime) that previously shipped a wrapper Terminal layer implementing exactly this queue-end behavior: with this change applied to the installed package and the wrapper removed, its full CLI test suite passes, including
printf 'y\n' | cliprompt flows and prompt interruption via closed stdin.Happy to add a spawned-fixture test for the piped-stdin case if you'd like one — I didn't see existing NodeTerminal coverage to extend.
Summary by CodeRabbit
Terminal.QuitErrorinstead of hanging after input is closed or piped.readLinenow fails immediately for readers created after input has already ended.