Several parser goroutines each close the shared records channel and it panics with "send on closed channel". How do you fix it?

## Reading the panic `panic: send on closed channel` with a stack whose top frame is inside a parser goroutine tells you two things. The parser was still legitimately producing, and somebody had already declared the stream finished. The closing goroutine is usually *not* on the trace, because its `close` call returned long before the panic — so the trace names the victim, not the culprit. When several goroutines run the same producer function, that is the strongest hint: look for a `close` inside the function that more than one goroutine runs. In a code generator whose parsers each walk part of a schema and emit record descriptors onto one shared channel, the buggy shape is exactly this: ```go func parse(files []string, records chan<- Record) { defer close(records) // wrong: every parser does this for _, f := range files { records <- Record{File: f} } } ``` The `defer close(records)` reads like "I'm done", but that is not what `close` means. ## Why `close` cannot be per-sender `close` records one fact about the channel: no further values will ever be sent on it, by anyone. It is a statement about the *stream*, not about the calling goroutine's contribution to it. With N senders, no individual sender has the information needed to make that statement — it does not know whether its peers have finished. This is the point that engineers coming from languages whose queues expose a closeable, multi-writer API most often have to unlearn: there, `close` frequently means "this writer is finished", and the queue tracks the writer count for you. Go's channel keeps no such count. ## Why `sync.Once` is not the fix The instinct after seeing `close of closed channel` is to make the close happen once: ```go var once sync.Once once.Do(func() { close(records) }) ``` That is a correct fix for the wrong problem. The double close is gone, but the *first* close still happens while other parsers are mid-loop, so the failure mode shifts from a panic in the closer to `send on closed channel` in a peer — non-deterministic, dependent on scheduling and input size, and far more likely to reach production before it is noticed. `sync.Once` around a close is only appropriate when you already know no sender can still be running; and if you know that, you did not need the `Once`. ## Fix 1: one owner closes, after every sender has returned The goroutine that started the parsers is the only party that knows when they have all finished. So it joins them and closes afterwards: - launch the parsers, - wait for every one of them to return, - then `close(records)`, - and the consumer's `for rec := range records` loop ends by itself. By construction there is no sender alive when `close` runs, so neither panic is reachable. Note the structural requirement this creates: the closing goroutine must not be the one draining `records`, or it will block waiting for parsers that are themselves blocked sending to it. The consumer runs concurrently with the join. ## Fix 2: don't close the data channel at all If the reason the parsers must stop is that the *consumer* is abandoning the job — the generator hit a fatal template error and no further records are wanted — then closing `records` is doubly wrong: the receiver would be closing a channel it only reads. Instead, keep `records` open and have the receiver close a separate `done chan struct{}`. Closing broadcasts, so every parser sees it, and each one selects between making progress and giving up: A parser's send becomes a `select` between `records <- rec` and `<-done`. Nobody ever closes `records`, which is fine: closing is only needed when a receiver's control flow depends on the end of the stream, and here the receiver is the one calling it off. ## Encoding the rule in signatures Write directions into parameter types. A parser that takes `records chan<- Record` and `done <-chan struct{}` can send records and can observe cancellation, and the compiler rejects `close(done)` inside it because a receive-only channel cannot be closed. The convention "the sender closes, and only when it is the sole sender" then stops being a comment and becomes something review does not have to catch by eye. ## What to say in the interview Diagnose from the panic (a producer function run by several goroutines that contains its own `close`), reject `sync.Once` explicitly and say why (it moves the panic rather than removing it), then give both fixes and the condition that selects between them: close when the consumer must detect the end, and don't close at all when the consumer is the one calling it off.