[BUG] Dashboard metrics never recover after the window is hidden >2 min — heartbeats 404 against swept sessions, values silently freeze until app restart

Title

Dashboard metrics never recover after the window is hidden >2 min — heartbeats 404 against swept sessions, values silently freeze until app restart

Platform

Desktop App - Windows

Server Installation Method

Proxmox (Community Scripts)

Version

2.7.1

CLI Installation Method

None

CLI Version

No response

Troubleshooting

• I have examined logs and tried to find the issue
• I have reviewed opened and closed issues
• I have tried restarting the application
• I have checked open issues and ensured this is not a duplicate

The Problem

If the Dashboard is out of sight for more than ~2 minutes — window minimized, or another
tab active — its host metrics never resume updating when it comes back. The cards do not
go blank: they repaint once with the last known values and then freeze silently,
while the client fires a burst of POST /metrics/heartbeat requests that all return
404, roughly one per host, repeating on a timer until the app is restarted. Nothing
surfaces in the UI; the only signs are stale numbers and a red console burst:

Failed to load resource: the server responded with a status of 404 (Not Found)
http://localhost:30005/metrics/heartbeat        (x28 per burst on my install)

Captured over the DevTools protocol (29 hosts, 28 with metric sessions — one host has no
reachable metrics endpoint):

• While the window is hidden, all /metrics/ traffic stops entirely — heartbeats are
  suspended, so after 120s the server sweeps the viewer sessions.
• On return, in two separate 3.5–4.5 min observation windows (one per repro path below):
  84 heartbeat POSTs, all 404, in 3 bursts of exactly 28, ~90s apart. No
  re-registration request is ever sent.
• Dashboard card values refresh once at the moment the tab/window comes back (a one-time
  fetch repaints last-known data), then stay bit-for-bit identical for the entire
  observation window. When healthy, the same probe shows values changing within ~30s.
• A host's own Host Metrics tab is immune: it stops its session on hide
  (POST /metrics/stop/<id>) and starts a fresh one on show (POST /metrics/start/<id>),
  after which its heartbeats return 200 and its values keep moving. Only the Dashboard's
  register-once-and-heartbeat sessions wedge.

How to Reproduce

1. Open the Dashboard, wait for host cards to show CPU/RAM/Disk.
2. Minimize the window (or switch to another tab in the app) for more than 2 minutes.
3. Return to the Dashboard with the DevTools console open.

Every return after a >2 min gap reproduces it (tested both the minimize path and the
switch-tab path). The cards show plausible but frozen values; the console shows the 404
bursts; only an app restart recovers live updates.

Additional Context

Reading the 2.7.1 sources, the pieces line up with what's on the wire:

1. The server sweeps a viewer session after 120s without a heartbeat
   (hosts/metrics/index.ts:974).
2. The client suspends heartbeats whenever the dashboard is not visible
   (DashboardTab.tsx:1483) — consistent with the observed total silence while hidden.
3. On becoming visible again it resumes heartbeating the old session IDs and never
   re-registers, because registration is guarded by if (!existing)
   (DashboardTab.tsx:1363) — consistent with 404s and no registration request ever
   appearing.
4. The failures are invisible because the heartbeat is fired as
   sendMetricsHeartbeat(...).catch(() => {}).

Even switching away to another tab and back — which re-fetches card data once and
repaints — does not re-register the sessions, so the "working-looking" dashboard is
serving stale data on top of a dead session layer. That silent-stale failure mode seems
worse than blank cards: there is no visual hint anything is wrong.

Observed on the Windows desktop app against its embedded backend (metrics service on
localhost:30005); nothing here looks desktop-specific — the sweep/guard logic is shared.
Happy to run anything specific or test a :beta build.

Start with DashboardTab.tsx around lines 1363 and 1483, then compare its dashboard session handling with the server sweep at hosts/metrics/index.ts:974. Reproduce the issue by hiding the dashboard for more than two minutes and inspect heartbeat and registration requests on return. Done means dashboard metrics resume updating after returning, without repeated heartbeat 404s or requiring an app restart.