In a Go pipeline handing `[]byte` pixel buffers between stages, what breaks if a stage reuses its scratch buffer?

## What a channel send actually copies Go channels copy values. That is the whole guarantee, and the trap is that for a slice the *value* is not the data. A `[]byte` is a three-word header: a pointer to a backing array, a length, and a capacity. Sending it copies those three words. The receiver gets its own header — reslicing on one side will not change the other side's length — but both headers point at the same array of bytes. So `out <- buf[:n]` does not hand over a photo. It hands over a *view* of a photo that the sender can still write through. ## The corruption timeline With one scratch buffer in the decode stage: 1. decode reads frame 1 into `buf` and sends `buf[:n]`; 2. resize receives that header and starts reading pixels out of the array; 3. decode loops, opens the next file, and reads frame 2 **into the same array**; 4. resize is now resizing a blend of frame 1 and frame 2. Nothing fails loudly. There is no bounds violation, no nil dereference, no failed send. The only symptom is wrong output: a thumbnail with a band of the wrong image in it, usually only under load, usually only in production. ## Is it a data race? Usually yes. The channel send/receive pair establishes a happens-before edge for the handover itself, but it says nothing about the sender's *later* writes relative to the receiver's reads. Those two accesses are unsynchronised, and the race detector can report them. The important qualifier is that the detector is a run-time observer, not a static check: it reports races that actually occur in the execution you exercise. A unit test with three small files, where each stage happens to finish before the next write lands, passes clean and proves nothing about a production run with large frames and every core busy. "`-race` was green" is evidence about one schedule, and treating it as proof of safety is the misconception this question exists to catch. There is also a variant with no race at all and still-wrong data — a buffered channel that lets decode run several frames ahead and overwrite an entry that has been received but not yet read. Ordering is not the same thing as ownership. ## The rule: a send transfers ownership State it as a rule about values, not about channels: **once a value has been sent, the sender must not touch anything reachable from it.** For an `int`, a `string` or an array field there is nothing reachable, and the copy really is complete. For a slice, a map, a pointer or a channel field, the header or pointer is copied and the target is shared, so a struct like ```go type Frame struct { Path string Pix []byte // shared with the receiver Width int // genuinely copied } ``` is half-copied: `Width` is independent, `Pix` is not. ## Two ways to hold the rule **Allocate per item.** `buf := make([]byte, n)` inside the loop. Each frame owns its bytes, nobody shares anything, and the collector cleans up as frames fall out of the chain. This is the default, and it is the right default: it is correct by construction and needs no comment. **Recycle explicitly.** Add a second channel of free buffers flowing the other way. The decode stage receives a buffer from it, fills it, and sends it downstream; the last stage that touches the pixels sends the buffer back on the free channel when it is finished. A buffer is reused only after its consumer has explicitly given it up, so ownership is still single-writer, and the free channel's capacity caps how many buffers exist at once. It is more machinery, and the machinery is the point: the handover is now visible in the code rather than assumed. ## When is recycling worth it? Only when a measurement says so — large per-frame buffers churning the heap, visible as allocation volume in a heap profile and as bytes per operation in a benchmark run with `-benchmem`. Reuse as a habit, applied before measuring, buys nothing and costs correctness. And when you do adopt it, weigh the ongoing cost honestly: you have converted a pipeline that was safe by construction into one whose correctness depends on a convention that every future contributor has to learn and every reviewer has to check.