Repository navigation
CLI: fix stalls and dropped logs after the ratatui 0.30 upgrade - #6003
Merged
Merged
Conversation
Since DioxusLabs#5954 (ratatui 0.29 -> 0.30), `Terminal::clear()` queries the cursor position, and `insert_before` - which the serve TUI called once per log line - ends with `clear()`. That query needs crossterm's input-reader lock, which our `EventStream` background thread holds whenever it is waiting for a key. So every log line blocked the serve loop for the 2s query timeout, errored, and was silently dropped. The lock is only free right after a keypress, which made `t`/`v` seem to work intermittently and let status updates (e.g. "Installing tooling", "Compiling n/m") stall for tens of seconds behind the log queue. Switch to ratatui's `scrolling-regions` implementation of `insert_before`. It scrolls a region above the viewport and draws the lines into the gap, so it never clears the frame or queries the cursor. That also lets `render_log` drop its manual cursor/padding hack and `ansi_buffer.rs`: logs are now built as styled `Line`s, word-wrapped with `Paragraph`, and inserted in one `insert_before` per render. Also drain the already-queued burst of trace messages in the serve loop before rendering, so cargo's ~1000 `Fresh ...` lines cost one scroll instead of one redraw each and keyboard input is not starved.
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
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
Since #5954 (ratatui 0.29 → 0.30), the
dx serveTUI stalls for ~2s on every log line and then silently drops it. Symptoms: the dashboard looks hung in odd places ("Installing tooling" / "Compiling n/m" for 30s+ with nothing printed), andt/vonly seem to work sometimes - especially not during a build with--traceon.Cause: in ratatui 0.30,
Terminal::clear()queries the cursor position (ESC[6n), andinsert_before- whichrender_logcalled once per log line - ends withclear(). The cursor query needs crossterm's input-reader lock, which theEventStreambackground thread holds while it is parked waiting for a key. So the query waits out its 2s timeout, errors, and the log line is lost. The lock is only free right after a keypress, hence the intermittent feel: atpressed mid-build lands only once the queued cargo output has been "rendered" (2s per line), and with--tracethat queue is ~1000 lines.Fix:
scrolling-regionsfeature. Itsinsert_beforesets a VT scroll region covering the rows above the viewport, scrolls that region, and draws the lines into the gap - it never clears the frame or queries the cursor (and the frame no longer flickers/redraws per log).render_logandserve/ansi_buffer.rsunnecessary: logs are built as styledLines, word-wrapped withParagraph, and inserted with a singleinsert_beforeper render. This is the "future" the old FIXME comments inrender_logdescribed.TraceController::try_recv+ a drain in the serve loop so an already-queued burst of trace messages is rendered in one pass instead of one redraw per line, keeping keyboard input responsive.unicode-segmentationdependency.Net: +54 / -232.
Test plan
Tested on macOS with a release build of
dioxus-components(dx serve --release -p preview --features native --macos), which previously reproduced this reliably:--tracefrom the start: ~1000 cargo lines render within the same second (before: 2s each / dropped).rthent×2 mid-build: each toggle handled the instant it was pressed (before: ~15s late).v,/(viewport resize) work mid-build; frame intact; logs present in scrollback; app launches.cargo clippy -p dioxus-cli --all-targetsclean;cargo test -p dioxus-cli --bin dx162/162.Note: scroll-region
insert_beforerelies on the terminal pushing lines scrolled off a top-anchored region into scrollback. That is standard (iTerm2, Terminal.app, tmux, kitty, Alacritty, WezTerm, VTE, Windows Terminal) but reviewers on other terminals may want to sanity-checkdx serve --tracescrollback.