fix: drain pending TTY input on shutdown to prevent DECRPM garbage#1692
Open
ChrisJr404 wants to merge 1 commit into
Open
fix: drain pending TTY input on shutdown to prevent DECRPM garbage#1692ChrisJr404 wants to merge 1 commit into
ChrisJr404 wants to merge 1 commit into
Conversation
When bubbletea queries terminal capabilities (DECRQM for modes 2026/2027) during initialization, the terminal answers asynchronously. For very short-lived programs, those replies can arrive after the input reader has been cancelled but before the TTY has been restored. The bytes then sit in the kernel TTY input queue and the user's shell reads them once the program exits, producing visible garbage like: ^[[?2026;2$y^[[?2027;1$y Reported in charmbracelet#1590, also seen with the spinner in charmbracelet/huh and in package-manager-style examples whenever the run is fast enough. Add platform-specific drainInput() called from restoreTerminalState() right before restoring the original TTY state: - linux/solaris/aix: ioctl TCFLSH with TCIFLUSH (0) - darwin/*bsd: ioctl TIOCFLUSH with FREAD (1) - windows: FlushConsoleInputBuffer - other: no-op fallback On unix the call is wrapped in a flush-then-poll loop with a 200ms budget so responses arriving in bursts (or over an SSH round trip) are caught instead of slipping through.
|
I've tried this fix and it works. LGTM |
miekg
reviewed
May 13, 2026
| @@ -0,0 +1,31 @@ | |||
| //go:build darwin || dragonfly || freebsd || netbsd || openbsd | |||
| // +build darwin dragonfly freebsd netbsd openbsd | |||
There was a problem hiding this comment.
these // +build lines have long been deprecated
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.
Fixes #1590.
Background
During init, bubbletea queries the terminal for synchronized output (mode 2026) and unicode core (mode 2027) support:
The terminal replies asynchronously with
DECRPMreports. The input reader normally consumes them, but in very short-lived programs, the replies can land after the reader has been cancelled and before the TTY is restored. The bytes then sit in the kernel TTY input queue and get read by the user's shell after the process exits, showing up as:Several people have hit this — it surfaces with the
huhspinner once the action is fast, and with thepackage-managerexample at low random delays. It's also reproducible on Ghostty / Windows Terminal / Wezterm + zsh/nushell with the small repro in the issue.Fix
Add a per-platform
drainInput()and call it fromrestoreTerminalStateright before we hand the TTY back to the shell:ioctl(fd, TCFLSH, TCIFLUSH)ioctl(fd, TIOCFLUSH, &FREAD)FlushConsoleInputBufferOn unix the call sits in a flush-then-poll loop with a 200 ms budget. Local terminals reply within microseconds and the loop exits on the first iteration; the budget exists so SSH round-trips (which often deliver replies in bursts after the first flush) don't slip through. The output flush in
restoreTerminalStateis preserved so renderer reset sequences still make it out.Verification
go test -race ./...passes locally on linux/amd64.go vet ./...clean.golangci-lint runclean for linux, darwin, freebsd, openbsd, netbsd, dragonfly, windows.CGO_ENABLED=0) succeeds on linux (amd64/arm64/arm/mips/mips64/ppc64/riscv64/s390x), darwin (amd64/arm64), freebsd, openbsd, netbsd, dragonfly, solaris, windows. AIX fails on an unrelatedultravioletsymbol (termios.GetWinsize), not on this change.drainInputI observed the second iteration finding 22 bytes pending (the two DECRPM replies) and discarding them, then the poll timing out so the loop exits cleanly. Without the fix those 22 bytes remain in the slave's input queue.Notes
restoreTerminalStatepath is also reached viareleaseTerminal(used bySuspend/Kill/ReleaseTerminal), so the drain runs there too — same race, same fix.Pollreturning<= 0rather than a fixed iteration count: if a misbehaving terminal somehow streams data forever the worst case is one extra 200 ms wait per iteration, which is still bounded by the read traffic actually being there.