Unfocused desktop polls diagnostics every 2 s and gets 1 Hz unchanged pushes #168

Summary

With the desktop window unfocused and unused all night, its client kept two streams running at full rate. It polled server.getProcessDiagnostics every 2 s (the status bar resource readout), and it received a subscribeDiscoveredLocalServers push every second, although nothing changed. That is about 11.5 MB/h of JSON into the webview, and 107 MB over the night. In the same hours, with no user activity and no thread events, the WebKitWebProcess's private memory rose steadily by about 6 MB/h, without the sawtooth that garbage collection normally leaves. This is the idle half of memory.leak-likely-c023666f632d (#96); the activity-driven half is #167.

Environment

Evidence (2026-10-22, 00:00–09:00Z)

• rpc.histogram and rpc.bytes agree per method, so all of this was the desktop window's client:
  • server.getProcessDiagnostics: exactly 159–160 calls in every 5-minute slot (108 slots), 17,271 in total, 31.7 MB.
  • subscribeDiscoveredLocalServers: 299–309 pushes per slot, 32,458 in total, 70.3 MB (2.2 KB on average, up to 64 KB).
  • subscribeVcsStatusSummary: 16,398 pushes, 4.8 MB.
  • server.refreshProviderUsage and server.getProviderUsage: 120/h each (the 30 s usage refresh).
• No client.batch arrived overnight: the profiler's own heartbeat already pauses while the window is unfocused, but these streams don't.
• No orchestration events at all from 00Z to 09Z.
• WebKitWebProcess private memory, hourly: 506, 510, 514, 521, 528, 532, 539, 543, 548, 554, 561 MB. That is monotonic, about 6 MB/h, with no drops.

Suspected source

• apps/web/src/components/status-bar/AppStatusBar.tsx:43: STATUS_BAR_RESOURCE_REFRESH_INTERVAL_MS = 2_000, with no pause while the window is hidden or unfocused.
• apps/server/src/production/server_terminal.rs:507: discovered_local_servers_stream sends the full server list with a fresh scannedAt every SCAN_INTERVAL (1 s, apps/server/src/production/local_servers.rs:15), changed or not.

Reproduction

1. Start the Linux desktop with the profiler on and leave the window unfocused for an hour.
2. Count getProcessDiagnostics and subscribeDiscoveredLocalServers in rpc.histogram and rpc.bytes: about 1,920 and 3,600 per hour.
3. Watch WebKitWebProcess privateBytes in process.sample.

Root-cause hypothesis

The traffic is certain and wasteful while nobody looks: CPU, battery and, on a remote client, bandwidth. Whether it causes the 6 MB/h idle growth (retained objects, or WebKit's allocator not giving freed memory back) is unproven without a heap snapshot. Confidence: high for the traffic; medium-low for it being the cause of the growth.

Suggested fix direction

• Pause the status bar's resource and usage polling while document.visibilityState is hidden or the window is unfocused; refresh once on focus.
• Push discovered servers only when the list changes, ignoring scannedAt, or send a heartbeat-free diff. Scanning can stay at 1 s while someone subscribes.
• The change doubles as the experiment: if overnight growth flattens after it, this was the cause; if not, take a WebKitGTK heap snapshot next.