Fix goroutine leak in queue package

[lxcxjxhx]

Fix Goroutine Leak in Queue Package

Problem

The queue package has a goroutine leak issue in the Stop() method. When Stop() is called while workers are still processing messages, the following sequence occurs:

1. Stop() calls q.cancel() to signal shutdown
2. reader() receives the cancellation signal and exits
3. However, workers blocked on q.queue channel may not exit immediately
4. This causes goroutines to leak, as they remain blocked indefinitely

Root Cause

The issue stems from the interaction between reader() and Stop():

• reader() has defer close(q.queue) which closes the channel when it exits
• Stop() calls q.cancel() but doesn't explicitly close the queue channel
• If reader() hasn't exited yet when Stop() checks q.ctx.Err(), workers can be left waiting on an open channel

Solution

1. Remove defer close(q.queue) from reader(): This prevents potential double-close panics
2. Add explicit close(q.queue) in Stop(): After calling q.cancel(), immediately close the queue channel to ensure all workers can exit their receive loops

Changes

• backend/pkg/queue/queue.go: Modified Stop() and reader() methods
  • Line 124: Added close(q.queue) after q.cancel() in Stop()
  • Line 167: Removed defer close(q.queue) from reader()

Impact

• Fixes goroutine leak: Workers now properly exit when Stop() is called
• Prevents resource exhaustion: Long-running applications won't accumulate leaked goroutines
• No breaking changes: The fix maintains the same external behavior and API

Testing

The fix ensures that:

• All worker goroutines exit when Stop() is called
• No double-close panics occur on the queue channel
• The queue can be safely stopped even while processing messages