What is context.Context in Go, and why is it passed as a function's first parameter?

## The problem it solves A server handles a request. Halfway through, the client hangs up, or the request has already burned its two-second budget. Everything still running on that request's behalf — a database query, an outbound HTTP call, a retry loop, three goroutines fanned out over shards — is now wasted work holding memory, a connection and a scheduler slot. Something has to tell all of it to stop. Many runtimes answer this with thread-local storage or a special cancellable task object. Go has neither: there is no goroutine-local storage, and a goroutine is not an object you hold a handle to. So Go answers it with an ordinary value that you pass along: `context.Context`. ## What the value actually is `context.Context` is an interface with four methods: ```go type Context interface { Deadline() (deadline time.Time, ok bool) Done() <-chan struct{} Err() error Value(key any) any } ``` A callee that receives one can ask three useful questions and read one piece of request-scoped data: - **"Should I stop?"** — `Done()` returns a receive-only channel that is *closed* when the work should be abandoned. Closing is the signal; a closed channel makes every receive succeed immediately, so any number of goroutines can watch the same one. - **"Why did I stop?"** — `Err()` returns `nil` while the work is still live, and a non-nil error once `Done` is closed. - **"How long do I have?"** — `Deadline()` returns a time and a boolean saying whether a deadline was set at all. - **"What request is this?"** — `Value(key)` looks up request-scoped data such as a request or trace identifier. A `Context` is **immutable**. Nothing you can call on it changes it. You do not "set a deadline on a context"; you *derive a new context* from it with one of the `context.With…` functions, and pass the child down. That immutability is what makes it safe to hand the same `ctx` to several goroutines at once with no locking. ## Why it is the first parameter The convention — stated in the `context` package documentation itself — is that a function taking a context takes it as its **first** parameter, conventionally named `ctx`: ```go func (s *Store) Order(ctx context.Context, id string) (*Order, error) ``` This is a pure convention; the compiler does not care. It exists because it is *mechanically checkable*. A reviewer scanning a diff, or a lint rule in CI, can see at a glance whether every exported call in a package is cancellable, because a cancellable one always looks the same. Put it third, or hide it in a struct field, and "is this call cancellable?" becomes a question you have to answer by reading the body. The matching rule is that you **never pass `nil`** as a context, even to a function that would tolerate it. If you genuinely have no context to hand — you are at the top of `main`, in a test, or in code that has not been plumbed yet — pass an explicit empty root instead. ## Cooperative, not forcible The single most common misunderstanding is that cancelling a context *stops* something. It does not. Go cannot kill a goroutine from the outside; there is no `goroutine.Kill()`. All cancellation does is close a channel. Every function in the chain has to opt in to noticing: ```go func work(ctx context.Context, items []string) error { for _, it := range items { select { case <-ctx.Done(): return ctx.Err() default: } process(it) } return nil } ``` In practice most functions never write that loop, because they simply pass `ctx` on to something that already honours it — a database call, an outbound HTTP request — and the check happens down there. That is exactly why *propagation* is the whole game. The chain is only as cancellable as its least diligent link: one helper that takes no context, or that quietly starts a fresh empty root of its own, severs the signal for everything below it, and the deadline the caller set no longer means anything. ## What it is not It is not a general-purpose argument bag. Anything the callee needs in order to do its job — a database handle, a logger, configuration, an ID — is a parameter or a field on the receiver. The context carries the *request's* cross-cutting concerns: when to stop, and the few identifiers that describe which request this is. It is also not a scheduling primitive. It starts nothing, joins nothing and waits for nothing. It is a one-way broadcast that says "whoever is working on my behalf may stop now."