The Monitor That Loaded Fine but Wouldn't Load

INFRASTRUCTURE REPORT — MONITOR AVAILABILITY INCIDENT Two complaints arrived back to back: the Stream Health monitor "isn't loading," and the phone dashboard "isn't running." The tempting move — blame the recent changes — is almost always the wrong first move. REPRODUCE, DON'T THEORIZE A compile check proves nothing for a GUI app; the failure mode is a hang, not an exception. A timed stack-trace capture gave the real datapoint: the main thread was sitting happily in the GUI loop, workers asleep in their normal loops. The monitor loaded fine. So why "isn't loading"? Two stale instances were already running, and nobody was holding the API port. ROOT CAUSE #1 — THE WEDGED HUSKS The two "running" instances were husks: each down to a single thread. A healthy instance runs many — GUI, poller, API server, watchdog. Every worker thread had died. No window mapped (so nothing appeared to load), and the API port bound by nobody (so the phone had nothing to talk to). Same rotten cause behind both complaints. Both husks predated the latest edits, so they ran stale bytecode and would never reflect a fix. The cure: kill the stale processes, clear the cached bytecode, relaunch clean. ROOT CAUSE #2 — THE FREEZE THAT LOOKED LIKE A CRASH But why did operators end up with multiple stale instances? Startup mounted all eight module tabs synchronously before entering the main loop. For a few seconds the window exists but sits frozen and blank — indistinguishable from "not loading" — so a human launches it again. And again. The durable fix: mount tabs progressively, one per idle tick, so the shell paints instantly and fills in over a fraction of a second. CONTAINMENT NOTE: "Won't load" is often "loaded, but you can't tell." And watch your watchdogs — the one here cried "hung" when the app was merely busy, sending every future investigator down the wrong path.