Caught a check-then-act race on our session cache and handed me a double-checked lock fix in Go

The bug is a check-then-act race on the in-memory session cache. Two goroutines read `cache[id]` as missing, both build a session, and one overwrites the other — under load this drops logins intermittently. **Race identified:** `Get` reads the map without a lock; `Set` writes under a lock. A concurrent read during a write is a data race (Go's race detector flags it as read/write on the same `map`). ```go // BEFORE — unsynchronized read, lost-update on miss type SessionCache struct { mu sync.Mutex m map[string]*Session } func (c *SessionCache) Get(id string) *Session { return c.m[id] // RACE: read without holding mu } ``` **Fixed — single-flight load under a lock so only one builder runs per key:** ```go type SessionCache struct { mu sync.RWMutex m map[string]*Session } func (c *SessionCache) GetOrCreate(id string, build func() *Session) *Session { c.mu.RLock() if s, ok := c.m[id]; ok { // fast path: shared read lock c.mu.RUnlock() return s } c.mu.RUnlock() c.mu.Lock() // slow path: exclusive defer c.mu.Unlock() if s, ok := c.m[id]; ok { // re-check after acquiring write lock return s // another goroutine won the race } s := build() c.m[id] = s return s } ``` **Why it works:** the double-check under the write lock guarantees exactly one `build()` per key even when many goroutines miss simultaneously — the happens-before edge is the `Lock`/`Unlock` pair. **Reproduce:** run the test with `go test -race -count=100` firing 200 concurrent `GetOrCreate` calls for one id; pre-fix it reports a data race, post-fix it is clean. **Alternative:** `sync.Map` or `golang.org/x/sync/singleflight` if you'd rather not own the locking.