Summary

• Fix a race condition in ConnStateMachine.notifyWaiters() that breaks FIFO execution ordering of queued waiters

Problem

• notifyWaiters() re-reads the atomic state (sm.GetState()) on every iteration of its outer loop. When a woken goroutine runs fast enough to call Transition(StateIdle) before the loop iterates again, the function sees the new state and wakes the next waiter within the same mutex hold. This cascades — potentially notifying all queued waiters in a single call. Since they all become runnable simultaneously, the Go scheduler executes them in arbitrary order, violating the FIFO guarantee.

• Example: With waiters queued as [0, 1, 2, 3, 4, 5, 6, 7, 8, 9], the observed execution order was [0, 1, 9, 2, 3, 4, 5, 6, 7, 8].

• This caused flaky failures in TestConnStateMachine_FIFOOrdering across multiple CI matrix entries (8.0.x stable, 8.2.x 1.25.x, 8.4.x stable).

Fix

Read the state once at entry, and after a successful CAS, update a local state variable to w.targetState instead of re-reading the atomic. This ensures notifyWaiters only considers transitions made within its own call, not concurrent transitions from woken goroutines. The CAS failure path still re-reads the atomic (correctly — an external change requires the real value).