I think it always a mistake to start a goroutine without passing a context to it, since you are no longer able to cancel the goroutine unless you build your own mechanism to do so. Given that, I think you can handwave it a bit and regard context variables as goroutine local.
>I think it always a mistake to start a goroutine without passing a context to it, since you are no longer able to cancel the goroutine unless you build your own mechanism to do so
Not really a problem. If you pass a channel you can close the channel. And cancel isn't magical, still need to handle it from within a goroutine and adding a timeout isn't any more or less complex than handling context cancellation
> Given that, I think you can handwave it a bit and regard context variables as goroutine local.
That's extremely wrong way to handle it, especially if it is in a bigger app. There is nothing stopping from changing the values in it in other goroutines for example, and one of designed uses of ctx is scatter-gather pattern of spawning multiple parallel tasks that need to be done to respond to request, and other is using ctx to pass data between middlewares (as is often used in web frameworks in Go at least). So you have to at least take care about variable naming across the project and parallel access to them might happen so you need to take care about not running 2 goroutines wanting to write into same variable.
