Why Your Go Function Returns While Goroutine Stays Alive—and How to Fix It

Go’s concurrency model feels clean and safe, which often leads developers to assume that using channel, goroutine, and select automatically prevents resource leaks. In reality, a common interview pattern reveals a subtle bug: the function returns while a background goroutine remains blocked, causing a goroutine leak.

Problem Demonstration

The interview code looks like this:

func fetchResult(ctx context.Context) (string, error) {
    ch := make(chan string)
    go func() {
        result := doWork()
        ch <- result
    }()
    select {
    case res := <-ch:
        return res, nil
    case <-ctx.Done():
        return "", ctx.Err()
    }
}

At first glance the logic appears balanced: a normal path that returns the result and a cancellation path that returns early. However, when ctx.Done() fires, the function returns immediately, but the goroutine continues to execute doWork() and then tries to send the result on the unbuffered channel ch. Since the receiver has already exited, the send blocks forever, leaving the goroutine hanging.

This leak is silent—no panic, no obvious error—yet each cancelled request leaves a stray goroutine that consumes memory and CPU. Under high load the accumulated leaks cause the service to become slower and eventually unstable.

Interview Insight

The interviewer points out the issue: “This goroutine will block forever on send. Your function returned, but you didn’t provide an exit path for the goroutine.” The key lesson is that checking a function’s clean return is not enough; you must also ensure any spawned goroutine can exit cleanly.

Fixing the Leak

The minimal fix is to give the channel a buffer of size 1, allowing the goroutine to complete the send even after the caller has returned:

ch := make(chan string, 1)

While this prevents the block, a more robust solution passes the context into the goroutine and selects on both the send and the cancellation signal:

go func() {
    result := doWork()
    select {
    case ch <- result:
    case <-ctx.Done():
    }
}()

This pattern creates a contract: “If the caller is still listening, send the result; otherwise, exit.” Many teams adopt this as a default style because it forces explicit handling of both success and cancellation paths.

Additional Considerations

Adding a buffer only solves the send‑blocking issue; it does not stop doWork() from doing unnecessary work after cancellation. For I/O‑heavy or long‑running tasks, the context should be propagated down to every sub‑call (e.g., http.NewRequestWithContext, database queries, gRPC stubs) so the work itself can be aborted.

Testing for leaks can be automated with the goleak package. Adding goleak.VerifyNone(t) at the end of tests catches many regressions before they reach production, though it cannot cover every scenario.

Best‑Practice Checklist

Before launching a goroutine, enumerate all exit paths of the caller and ensure none leave a blocked send.

When a goroutine sends a result, guarantee a receiver exists or use a buffered channel.

If the task involves costly I/O or computation, pass a context and make the work itself cancellable.

These rules don’t eliminate every concurrency bug, but they dramatically reduce the likelihood of hidden goroutine leaks that silently degrade service reliability.