A `go worker()` call returns no value, so how does a supervisor goroutine learn that the worker exited and why?

## The `go` statement gives you nothing back `go f()` starts `f` in a new goroutine and the statement completes immediately. It is a statement, not an expression: it has no value, there is no handle object, and there is no way to "join" a goroutine and read its result the way you might await a task in other runtimes. The language deliberately offers exactly one way to get information out of a goroutine — communication over a channel (or a `sync` primitive plus shared memory, which is the same idea with more foot-guns). That is the whole reason a supervisor exists as a separate goroutine: something has to be blocked, waiting to be told that the worker is gone. ## The exit channel The standard shape is a wrapper goroutine whose only job is to call the worker and forward its return value: ```go exits := make(chan error, 1) go func() { exits <- dial(ctx) }() ``` `dial` here is the long-lived work — for a session manager, open a socket to a remote device, read frames from it until the connection dies, and return the error that ended it. The wrapper turns "the function returned" into "a value appeared on a channel", which is something a `select` can wait on alongside everything else the supervisor cares about. The error value is the report. Return `nil` for an orderly stop (the context was cancelled, the peer closed cleanly) and a non-nil error otherwise; wrap it with `fmt.Errorf("...: %w", err)` so the supervisor can log a reason a human can act on. ## Why the channel is buffered by one An unbuffered send blocks until a receiver is ready. If the supervisor has returned — because shutdown finished, or because it gave up on this worker — nobody will ever receive, and the worker goroutine blocks on the send forever. That is a goroutine leak: it holds its stack, and anything it references, for the life of the process. Giving the channel a buffer of one lets the final send complete unconditionally, and the value is simply discarded when the channel becomes unreachable. ## The supervisor loop ```go for { select { case <-ctx.Done(): return case err := <-exits: // worker is gone; decide what to do about it } } ``` Two cases, two reasons to wake up. `ctx.Done()` is the shutdown path: the supervisor stops looping and returns; the worker sees the same cancelled context and unwinds on its own. The `exits` case is the interesting one: the worker died on its own terms and the supervisor now owns the decision to relaunch. The check that beginners miss sits inside that second case. After a shutdown starts, in-flight workers return almost immediately — with an error, because their socket read was interrupted. If the supervisor relaunches blindly it will start a fresh worker during shutdown, and possibly loop doing so. Test `ctx.Err() != nil` (or `errors.Is(err, context.Canceled)`) and return instead. ## Many workers, one channel With a session per remote device you do not want a channel per worker in the `select`; `select` cases are fixed at compile time. Send a small struct instead: ```go type exit struct { device string err error } ``` One `chan exit` buffered to the number of workers lets a single supervisor loop learn which worker died and why, and relaunch just that one. ## What not to do Writing the result into a shared variable and reading it from the supervisor is a data race unless something synchronises the two goroutines; a channel send and the matching receive give you that synchronisation for free, which is why the idiom is a channel and not a package-level `var lastErr error`. A `sync.WaitGroup` is also not a substitute here. It tells you that everything you counted has finished; it carries no value and cannot tell you *which* worker stopped or *why*. A `WaitGroup` is how you wait for a shutdown to complete; a channel is how you learn about an individual exit.