Why a Watchdog Timer Can Pass All Tests Yet Still Leave a Session Hung

A software engineering post-mortem examines SLICE-012 in the Ranex harness fork, where a stalled provider stream had no timeout, causing its coordinator to never settle and keeping the active session indefinitely busy. The core finding is that a watchdog timer only resolves a stall when its failure path reaches a terminal, non-retryable state; a retryable timeout can silently recreate the original hang in a loop. The fix required explicitly classifying both watchdog failure types as non-retryable errors, a small wording change with significant operational consequences. The analysis also highlights why a single timeout threshold is insufficient: an idle deadline detects silence between chunks, while a separate absolute budget caps total turn duration, and each must be tested independently. The post concludes that operators need a guaranteed terminal state, not a retry mechanism that produces a more active version of the same stuck condition.