Repository navigation
The TUI shows only what the daemon wrote, and never fetches #366
Description
Current state
The TUI and the daemon both fetch every source and both write the cache, so a notification and the list on screen can come from different passes, and nothing says which is newer. The TUI refreshes on its own timer and on r.
Ideal state
- The TUI never asks a source for signals: it shows the cache the daemon wrote
- With the daemon stopped, the TUI shows the cached signals, how old they are, and that the daemon is down
Decisions
Constraints
- 021 — The daemon owns signal refresh and is the only cache writer — the TUI stops writing the cache
- 022 — The TUI reads the cache and never fetches — no fallback fetch when the daemon is down, and no flag that re-enables one
Open
No open decisions.
Starting points
ui/tui/src/main.rs— the refresh timer and the cache writestore/src/status_cache.rs—upsert, the write the TUI stops making
Depends on
- "Pressing r refreshes the signals through the daemon": without it,
rwould have nothing left to do
Activity
ooloth commentedon Oct 18, 2026
#364 left one case to this issue. A daemon pass that runs on schedule but reaches no source, or fails outright, records
no_source_answeredorpass_failed, and the status bar says nothing about it, because today the TUI's own fetch usually fails the same way and names the failed sources itself. Once the TUI stops fetching, nothing reports a daemon that runs but brings back no signals, so the status bar should warn about it here. The record already holds the outcome, andDaemonRecord::statusindomain/src/daemon_health.rsis where its meaning is decided.