The office THOR PC's log for 2026-09-22 contains a textbook WPF defect, visible
without any instrumentation.
85% of a day's logging is one message: "UnitOperatingModeViewModel - Start/stop
monitoring request timed out: False", 178 of 209 lines. Only 12 lines describe
an actual operation.
Grouping that message by exact timestamp to the millisecond -- so each group is
ONE logical event -- the count per event grows over the day:
11:48 1-4
13:36-13:40 2-4
15:16 3
16:03-16:07 6
22:00-22:06 12
1 -> 12 over ten hours of uptime. Twelve identical lines sharing a single
millisecond is not twelve events; it is one event dispatched to twelve handlers.
That is a subscription leak, and the class name identifies it. THOR is .NET/WPF
("App thread", ViewModel naming), where a view model subscribing on view-open and
never unsubscribing on view-close is the archetypal case.
Consequences that follow directly: N grows without bound with uptime and usage;
every notification does N times the work; and a restart resets N to 1 -- matching
the operator's report that only restarting recovers a degraded session. The only
five "timed out: True" entries in the file sit at the very top, an episode caught
just before rotation.
Claim discipline stated explicitly in the doc. ESTABLISHED: the handler count
grows. STRONG INFERENCE: it is a subscription leak. NOT ESTABLISHED: that it
caused the 2026-09-22 field outage -- this log does not cover that window and the
link between leaked handlers and a dead TCP path is unproven.
Includes a ten-minute confirmation procedure: restart THOR, note the burst size,
open and close a unit detail view ten times, re-count.
Three lessons for SFM: unsubscribe on teardown or use weak events; log once per
event rather than once per handler; and log what CHANGED -- 178 "timed out:
False" lines are noise that buried the five that mattered, which is plausibly why
this went unnoticed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ru8Lg9HkkYvX9VWWo65SmL