The SageTUI-based TUI (default, non-legacy) locks up — no keyboard input, no rendering updates.
- Upgraded SageTUI from 0.9.3 → 0.9.4
- Temporarily disabled
Program.withDebuggerto isolate the issue
- The
sseSubsubscription callsDaemonClient.runSseListener runSseListenerdoes a blockingGetStreamAsynccall- The
/api/stateendpoint in Dashboard.fs should immediately callpushJson()before subscribing to state changes (line 78 in createApiStateHandler) - Test: Add logging to
runSseListenerto see if the connection establishes and if data arrives
- The
App.runcall from SageTUI might be blocking on something internal - Could be related to terminal size detection, initial render, or subscription setup
- Test: Add logging in
init,update, andviewto see which one never returns
Program.withDebuggermight have introduced a deadlock or blocking behavior- Wraps model in
DebuggerModel<Model>and messages inDebuggerMsg<Msg> - Status: DISABLED in v0.6.226 — if lockup persists, this hypothesis is ruled out
- The pre-flight connectivity check (line 763 in SageTuiClient.fs) succeeds
- But between that check and the SSE connection, the daemon might not be fully ready
- Test: Add a small delay or retry logic after connectivity check
- Reproduce locally:
sagefs tuiwith a fresh daemon - Add instrumentation: Log statements in
sseSub,init,update,view - Check SageTUI 0.9.4 CHANGELOG: Review for any breaking behavioral changes (already reviewed — only additive)
- Bisect: If needed, test with SageTUI 0.9.3 to confirm 0.9.4 isn't the cause
- Minimal repro: Create a trivial SageTUI app with SSE subscription to isolate SageFs-specific issues
SageFs/SageTuiClient.fs— TUI client implementationSageFs.Core/DaemonClient.fs— SSE listener (runSseListener)SageFs/Dashboard.fs—/api/stateendpoint (createApiStateHandler)C:\Code\Repos\SageTUI\Tea.fs— CustomSub implementation
- The legacy TUI (
TuiClient.fs) is imperative and has 0% coverage — scheduled for removal in Phase A3 - The SageTUI-based TUI (
SageTuiClient.fs) is the production path — DO NOT REMOVE