How to Fix Concurrency Issues in Go Code from Cursor

1---
2description: Go concurrency safety patterns
3globs: "*.go"
4alwaysApply: true
5---
6
7# Go Concurrency Rules
8
9## Channel Safety:
10- ALWAYS use buffered channels when the sender should not block
11- ALWAYS close channels from the sender side, never the receiver
12- NEVER read from a nil channel (blocks forever)
13- Use select with a default case to prevent blocking
14- Use context.Done() channel for cancellation in select statements
15
16## Goroutine Lifecycle:
17- EVERY goroutine must have a clear termination path
18- ALWAYS use sync.WaitGroup or errgroup.Group to wait for goroutines
19- ALWAYS pass context.Context as first parameter to goroutine functions
20- NEVER launch goroutines that outlive their parent function without lifecycle management
21
22## Shared State:
23- PREFER channels over shared memory for communication
24- When using shared state, ALWAYS protect with sync.Mutex or sync.RWMutex
25- Use atomic operations for simple counters
26- NEVER pass a mutex by value
27
28## Anti-Patterns (NEVER):
29```go
30go func() { /* no way to stop this */ }()        // goroutine leak
31ch := make(chan int) // unbuffered + single goroutine = deadlock risk
32time.Sleep(time.Second) // NEVER use sleep for synchronization
33```

1@go-concurrency.mdc
2
3Create a worker pool in Go with these requirements:
41. Configurable number of workers (numWorkers int)
52. Input channel for jobs, output channel for results
63. context.Context for cancellation — all workers stop when context is cancelled
74. errgroup.Group to wait for all workers and propagate the first error
85. Graceful shutdown: drain remaining jobs before exiting
96. No goroutine leaks: every goroutine must exit when the pool stops
10
11The job type is func(ctx context.Context) (Result, error).
12Include a NewPool constructor, Start, Submit, and Shutdown methods.

1@go-concurrency.mdc @codebase
2
3Audit this Go project for concurrency safety issues. Check for:
41. Goroutines launched without context cancellation support
52. Unbuffered channels that could deadlock
63. Channels that are never closed (goroutine leak risk)
74. Shared variables accessed from multiple goroutines without sync
85. time.Sleep used for synchronization instead of proper primitives
96. Missing WaitGroup or errgroup for goroutine lifecycle
10
11For each issue, show the file, the problematic code, and the fix.

1@go-concurrency.mdc
2
3Create a thread-safe in-memory pub/sub broker in Go:
41. Subscribe(topic string) returns a <-chan Message and an unsubscribe func
52. Publish(topic string, msg Message) sends to all subscribers non-blocking
63. Use sync.RWMutex for the subscriber map
74. Buffered subscriber channels (buffer size 100)
85. Drop messages if subscriber channel is full (non-blocking send)
96. Unsubscribe closes the channel and removes from the map
107. Close() method that unsubscribes all and prevents new subscriptions
11
12Ensure no goroutine leaks and no panics from sending on closed channels.

1@go-concurrency.mdc @pkg/worker/pool.go
2
3Generate tests for the worker pool that exercise concurrency:
41. TestPool_ConcurrentSubmit — submit 1000 jobs from 50 goroutines
52. TestPool_ContextCancellation — cancel context mid-processing
63. TestPool_GracefulShutdown — submit jobs then shutdown, verify all complete
74. TestPool_ErrorPropagation — submit a failing job, verify error returned
85. TestPool_NoGoroutineLeaks — use goleak to verify no leaked goroutines
9
10All tests must pass with go test -race -count=100.
11Use t.Parallel() where appropriate.