What
Three states in the UI are indistinguishable from breakage even though the app is working:
- A newly added instance shows Wanted/Eligible 0 until its first snapshot lands, which looks identical to a healthy empty instance. If that first snapshot fetch fails on a transport error, the only trace is a debug-level log line, so the card can sit at 0/0/0 indefinitely with no visible signal.
- Run now on an instance with nothing to search returns 202, shows the success state on the button, and writes no history rows at all.
- Test connection reports the app name and version but not the *arr's self-reported instance name, so pointing a Houndarr instance at the wrong Radarr (a 4K container, an old stack) is hard to self-diagnose.
Why
Two Discord threads in the last two months were users mistaking these states for bugs: a Sonarr card stuck at 0/0/0 right after a full stack reset, and a history view showing titles from a different Radarr than the one the user was looking at. Both turned out to be timing or configuration on the user's side, but the UI gave them nothing to rule that out with.
Proposed change
- Dashboard cards render a waiting-for-first-sync state (muted values plus the existing refresh pill) while an enabled instance has never completed a snapshot, and the supervisor logs a warning on the first consecutive snapshot transport failure per instance instead of debug only.
- A run-now cycle that ends with zero history rows writes one info row saying there was nothing to evaluate.
- Test connection includes the *arr's instanceName when it differs from the app name.
- FAQ entries covering "history shows titles that aren't in my library" and "a new instance shows 0 wanted".
Acceptance criteria
- An enabled instance that has never completed a snapshot shows the first-sync state, not a bare 0/0/0.
- Run now always leaves at least one history row, whatever the instance state.
- Test connection against an *arr with a custom instance name shows that name; default names render as today.
- Existing search-log characterisation tests stay green.
Out of scope
Engine scheduling or search behavior, schema changes, in-app education copy beyond the two state signals.
What
Three states in the UI are indistinguishable from breakage even though the app is working:
Why
Two Discord threads in the last two months were users mistaking these states for bugs: a Sonarr card stuck at 0/0/0 right after a full stack reset, and a history view showing titles from a different Radarr than the one the user was looking at. Both turned out to be timing or configuration on the user's side, but the UI gave them nothing to rule that out with.
Proposed change
Acceptance criteria
Out of scope
Engine scheduling or search behavior, schema changes, in-app education copy beyond the two state signals.