Description
The test "calls recordProbeTimeout when probe times out" sets up a fetchMock that never resolves, then races mgr.tick() against a 100ms timeout. After the race, it calls mgr.stop() but never asserts that recordProbeTimeout was actually called.
Worse: PROBE_TIMEOUT_MS in the source is 5000ms, so the probe's internal timeout never fires in the 100ms race window. recordProbeTimeout is genuinely never called — the test is a false positive.
Location
tests/health-probe.test.ts:40-63
src/health-probe.ts:5 (PROBE_TIMEOUT_MS = 5000)
Suggested Fix
Either:
- Reduce PROBE_TIMEOUT_MS via dependency injection for testing
- Mock the internal timer
- At minimum, add
expect(recordProbeTimeout).toHaveBeenCalled() to expose the gap
Severity
Critical — false positive test gives false confidence in health probe timeout handling
Description
The test
"calls recordProbeTimeout when probe times out"sets up a fetchMock that never resolves, then racesmgr.tick()against a 100ms timeout. After the race, it callsmgr.stop()but never asserts thatrecordProbeTimeoutwas actually called.Worse:
PROBE_TIMEOUT_MSin the source is 5000ms, so the probe's internal timeout never fires in the 100ms race window.recordProbeTimeoutis genuinely never called — the test is a false positive.Location
tests/health-probe.test.ts:40-63src/health-probe.ts:5(PROBE_TIMEOUT_MS = 5000)Suggested Fix
Either:
expect(recordProbeTimeout).toHaveBeenCalled()to expose the gapSeverity
Critical — false positive test gives false confidence in health probe timeout handling