Joseph Doherty
7da52b65b7
RunAsync_LongInFlightCommandThatKeepsPumping_DoesNotFaultAndDeliversReply failed deterministically on the Windows box with a StaHung fault whose command_method was empty and whose staleness was 233 ms — i.e. a fault raised with no command in flight, before the scenario under test began. FakeRuntimeSession stamps LastStaActivityUtc once, at construction, and the test only started refreshing it after the blocked dispatch signalled. Everything between those two points — handshake, STA init, the first heartbeat — captured a snapshot already stale past the compressed 50 ms grace, with no correlation id for the watchdog to suppress on, so the watchdog correctly reported the fake as hung. The harness, not the product, was wrong: StaRuntime.ThreadMain calls MarkActivity() on every WaitForWorkOrMessages iteration, so a live worker is never captured stale, idle or busy. Model that where it belongs — FakeRuntimeSession.RefreshStaActivityOnCapture (opt in, default off) stamps activity at each CaptureHeartbeat and leaves the rest of the snapshot alone — and arm it before RunAsync so the first beat is covered. The test-owned refresh loop goes away with it; a thread-pool loop racing a compressed grace could not have held the invariant anyway. Scenario intent is unchanged and slightly stronger: the command still blocks in dispatch across 30 heartbeats (~600 ms, many multiples of the 100 ms stuck ceiling), no frame may be a fault, and the reply must still arrive. The reply leg is now fault-checked too (previously it skipped frames blindly), and the pump keeps running across the release, as it does in production while the reply is marshalled off the STA. Fault assertions now report the category and diagnostic message instead of a bare body-case mismatch. Test-only change; no product code, frame protocol, or STA rule touched.