Or-channel

Canonical guidance

• use an or-channel to combine internal done signals
• keep the merged signal read-only to callers
• prefer context at external boundaries

Use when

• internal coordination of several cancellation sources
• waiting for the first shutdown signal
• bridging legacy done-channel code

Avoid

• returning many separate done channels when one merged signal is enough
• helper goroutines with no cleanup path
• using an or-channel where one parent context would be clearer

Preferred pattern

• expose one <-chan struct{} that closes when any internal stop condition fires

Anti-pattern

• selecting over five done channels at every call site

Explanation: This is tempting because it avoids a helper abstraction, but it scatters cancellation wiring everywhere.

Why

• cancellation composition should stay centralized