Go gives you no goroutine id and no goroutine-local storage, so how do you tag concurrent work with a request?

## What is missing, and on purpose Every goroutine has an internal number. You can see it: a panic prints `goroutine 17 [running]:`, and the goroutine profile groups stacks by them. What Go does not provide is any way for your program to *read* the current goroutine's id, and there is no goroutine-local storage either. This is a deliberate omission, not an oversight. The reasoning, argued by the Go team over many years of requests, is that an accessible id is the seed of goroutine-local storage, and goroutine-local storage makes a function's behaviour depend on invisible state attached to whoever called it. A library that reads its configuration from goroutine-local state behaves differently depending on which goroutine invoked it — and, worse, differently again when the caller does the natural Go thing and moves the work to a new goroutine, which inherits nothing. Making identity explicit keeps the data a function depends on visible in its signature. ## What you do instead Carry the identity in the value the work is done on: - **A parameter.** The plainest option, and the arguments of a `go` statement are evaluated in the calling goroutine, so passing an id snapshots it at that line. - **A field.** The goroutine works on a struct that already carries the run id, request id or worker index. - **A `context.Context`.** For request-scoped values that cross API boundaries — a request id, a trace id, an auth subject — `context.WithValue` is the sanctioned channel, and the context is passed to each goroutine as its first argument. Note the deliberate discipline around it: `WithValue` is for request-scoped data, not for smuggling optional parameters, and the key should be an unexported type so keys from different packages cannot collide. ```go type runIDKey struct{} ctx := context.WithValue(context.Background(), runIDKey{}, runID) for _, h := range hosts { go check(ctx, h) // every goroutine carries the run id explicitly } ``` The practical result is that log lines from concurrent work correlate because the *program* threaded the id through, not because the runtime kept a hidden map. ## The hack, and why it is a red flag The workaround people find is to call `runtime.Stack`, whose output begins with a line like `goroutine 42 [running]:`, and parse the number out of it. Reasons not to: - It is undocumented and unsupported; the format is not a stable interface. - It is slow — formatting a stack trace on a hot path is nothing like reading a variable. - **Ids are reused.** When a goroutine exits, its `g` structure goes back to a free list and the number can appear again on a completely unrelated goroutine, so anything keyed by id can silently attach one goroutine's state to another. In an interview, recognising this as a code smell — and naming the reuse problem — matters more than knowing the parsing trick exists. ## Where the ids are legitimately useful For humans, reading a dump. When a program panics, every goroutine's stack is printed with its number, and that number lets you follow one goroutine through a long dump or match a parked goroutine in the goroutine profile against the call site that started it. Diagnosis, not program logic. ## The same design, one step further The absence of an id is part of a wider pattern: a `go` statement hands back nothing at all. No id, no handle, no join, and no way to stop a goroutine from outside — `runtime.Goexit` terminates only the goroutine that calls it, running its deferred calls on the way out. Anything you want to know or control about a goroutine, you have to arrange when you start it. Once you internalise that, "how do I get the goroutine's id" stops being the question and "what did I pass in when I started it" becomes the answer. ## Coming from another language If you arrive from a runtime with thread ids and thread-locals, the honest translation is: the thing you used thread-local storage for is either a parameter now, or lives in a context. That is more typing at the call site and much less mystery at three in the morning, when the only question that matters is which request a log line belongs to.