Health check can schedule a reconnect while a registration attempt is in flight (race) #22

Summary

CI on master e7bedee (after #17 to #20 were merged) failed RegistrationHealthCheckInFlightTests: 4 reconnect attempts for 3 failures in default mode and 4 for 2 in extended mode. The same test passed on #19's branch.

Cause

PerformHealthCheck reads _registrationState without the lock. If it reads TemporaryFailure just before a scheduled attempt starts, its ScheduleReconnection() call runs after that attempt is already in flight. ScheduleReconnection() did not recheck the state, so it:

• started an attempt that no failure had asked for;
• in extended mode, stopped the in-flight agent, so that agent's own failure was never reported and the backoff skipped a step.

This is the same symptom #19 fixed at the health-check level. The remaining window is between the unlocked read and the lock.

Also seen

On a starved runner (reproduced here by pinning the tests to one CPU with taskset), the registration timing tests fail with gaps of almost exactly 1 s. SIPSorcery blocks thread-pool threads during each attempt, and with test classes running in parallel the pool grows by about one thread a second, so timers fire late. This is a test-environment problem, not a library bug.

Expected

ScheduleReconnection() refuses while an attempt is in flight, checked under the lock. The registration tests keep their timings on small runners.