Summary
Dashboard tab becomes unresponsive during active sessions — Chrome
shows the native "Page not responding" dialog and the user has to
choose between waiting and killing the tab. Repeatable enough that a
user reported it; needs investigation.
Likely a main-thread block on the dashboard side (long synchronous
work, runaway render, or unbounded state growth as session events
stream in), not a terminal-side rendering issue.
Observed
- Browser: Chrome (native unresponsive dialog: "此页面没有响应").
- Dashboard tab title:
Reasonix.
- TUI session was active with multiple concurrent jobs running
(visible in the screenshot: job 4, job 6 under 运行中).
- Project under work: a Node/TSX codebase (
habit-goal-tracker),
status line shows the session was non-trivial (token counters
populated, balance accruing).
Hypotheses to check
- Unbounded event/log accumulation. Every tool call / stream chunk
pushed into React state without virtualization → DOM grows
linearly with session length, scroll/repaint cost balloons.
- Synchronous work on the render path. Markdown / syntax
highlighting / diff rendering done eagerly per update instead of
memoized + windowed.
- Concurrent-job fan-in. Multiple jobs streaming simultaneously
may be multiplying re-render rate (N streams × M subscribers).
- Memory leak — listeners/timers not torn down across
session/route changes; check long-session heap snapshot.
- Tab in background. Chrome throttles background timers; if we
batch updates with setTimeout/requestIdleCallback, the queue
may explode and then flush in one blocking burst when the tab
refocuses.
Repro steps (to nail down)
Not yet a clean repro. Conditions present in the report:
- Long-running TUI session
- Multiple concurrent jobs
- Dashboard tab left open in Chrome the whole time
Action: try to reproduce with a synthetic long session + N concurrent
jobs, and capture a Performance recording when the freeze hits.
Asks
Summary
Dashboard tab becomes unresponsive during active sessions — Chrome
shows the native "Page not responding" dialog and the user has to
choose between waiting and killing the tab. Repeatable enough that a
user reported it; needs investigation.
Likely a main-thread block on the dashboard side (long synchronous
work, runaway render, or unbounded state growth as session events
stream in), not a terminal-side rendering issue.
Observed
Reasonix.(visible in the screenshot:
job 4,job 6under运行中).habit-goal-tracker),status line shows the session was non-trivial (token counters
populated, balance accruing).
Hypotheses to check
pushed into React state without virtualization → DOM grows
linearly with session length, scroll/repaint cost balloons.
highlighting / diff rendering done eagerly per update instead of
memoized + windowed.
may be multiplying re-render rate (N streams × M subscribers).
session/route changes; check long-session heap snapshot.
batch updates with
setTimeout/requestIdleCallback, the queuemay explode and then flush in one blocking burst when the tab
refocuses.
Repro steps (to nail down)
Not yet a clean repro. Conditions present in the report:
Action: try to reproduce with a synthetic long session + N concurrent
jobs, and capture a Performance recording when the freeze hits.
Asks
blocking?)
root cause