Fix race conditions in EWMA calculation and half-open state transitions

[Copilot]

Two concurrency bugs could prevent circuits from opening correctly or allow thundering herds during recovery.

Issues

EWMABreaker race condition: Concurrent observations read raw values (0.0/1.0) instead of the actual EWMA due to non-atomic read-modify-write:

// Before: Thread B reads Thread A's raw swap value
failureRate := fromStore(e.failureRate.Swap(toStore(value)))
// ...compute EWMA...
e.failureRate.Store(toStore(failureRate))  // Too late, corruption occurred

Half-open state: Multiple goroutines could simultaneously transition from half-open and all pass through, violating the "~1 call" limit.

Changes

• EWMABreaker.observe(): Replace swap-compute-store with CAS loop to atomically update EWMA based on actual previous value
• Circuit.stateForCall(): Use CAS to ensure only one goroutine wins half-open transition; losers re-check state in loop
• race_test.go: Add concurrency tests validating EWMA correctness and half-open limiting under load

// After: Atomic read-modify-write via CAS loop
for {
    oldBits := e.failureRate.Load()
    oldRate := fromStore(oldBits)
    failureRate = (value * e.decay) + (oldRate * (1 - e.decay))
    if e.failureRate.CompareAndSwap(oldBits, toStore(failureRate)) {
        break
    }
}

Verified with race detector and stress tests showing consistent max 1 concurrent call in half-open state.

Original prompt

This repository imolements a golang circuit breaker. Can you identify any issues in the code base? Limit yourself to issues that would cause a significant breach of expectations, e.g.: circuits not opening on errors, concurrency causing unrelated calls to fail, etc.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.