A client SDK stores the context.Context from NewClient in a struct field. What breaks?

## The rule and the reason The `context` package documentation states it directly: do not store a `Context` inside a struct type; pass it explicitly to each function that needs it, as the first parameter, named `ctx`. It is one of the few style rules in Go with a hard behavioural justification rather than an aesthetic one. A context is **request-scoped by construction**. It represents one caller's patience: one deadline, one cancellation signal, one set of identifiers. A struct field, by contrast, is **object-scoped**: it lives as long as the value does and is shared by every caller of every method. Putting the first inside the second commits the object permanently to one caller's answer to "when should this stop?" ## The two failure shapes Consider an SDK other teams import. ```go type Client struct { ctx context.Context // frozen at construction http *http.Client } func NewClient(ctx context.Context) *Client { … } func (c *Client) Get(path string) (*http.Response, error) { /* uses c.ctx */ } ``` Notice what the method signature now advertises: `Get(path string)` looks like a call that cannot be cancelled and has no deadline. A reviewer reading the *call site* has no way to know a context is involved at all. That invisibility is half the problem. **Shape one: the frozen request.** A caller constructs the client inside an HTTP handler, passing `r.Context()`, and caches the client for reuse. The handler returns; `net/http` cancels the request context; the client is now permanently poisoned. Every later call returns `context.Canceled` before a byte leaves the process. The symptom is brutal to read from the outside — a dependency appears to go hard-down with no network activity, and it recovers only on restart, because the poisoning is inherited from whichever request happened to build the client. **Shape two: the deaf client.** The more common variant: the constructor is called from `main` with `context.Background()`. Now nothing is ever cancelled. A caller that wraps its call in a two-second deadline gets no benefit at all — the SDK ignores it, because the outbound request was built with the stored root. Under load this is how a service ends up with far more in-flight upstream calls than it has live requests: each caller gave up, and nothing downstream ever heard. **Shape three, quieter: stale values.** Any request-scoped data attached to the stored context — a request or correlation identifier — is now attached to every call the client ever makes. The tenth request's outbound calls carry the first request's identifiers, and correlated logs point at the wrong request. ## The fix Move the context to the method. The struct keeps only things that genuinely belong to the object's lifetime: a transport, a base URL, credentials, a limiter. ```go type Client struct{ http *http.Client } func (c *Client) Get(ctx context.Context, path string) (*http.Response, error) ``` Now the signature tells the truth, the per-call budget is the caller's, and the client is genuinely safe to share across concurrent callers with different deadlines. For an SDK this matters more than in application code: a signature you export is a promise other teams build on, and adding `ctx` to a published method later is a breaking change for every one of them. Deciding this at v0 is cheap; deciding it after adoption is somebody's migration. ## The legitimate exceptions The rule is strong but not absolute, and knowing the exceptions is what separates a memorised rule from an understood one. - **A struct that *is* a request.** `http.Request` holds a context and exposes it via `Context()`, with `WithContext` producing a shallow copy carrying a new one. This is consistent, not contradictory: the struct's own scope *is* the request's scope, so the field cannot outlive what it describes. - **A long-lived component's own lifetime.** A daemon or worker loop may hold a context representing *its own* shutdown, derived at construction and cancelled by its `Close` method. It is not standing in for a caller's context; it is the object's lifetime. The tell is that no exported method uses it in place of a caller-supplied one — methods still take their own `ctx`, and the loop's own body watches the field. - **A struct being used purely as an argument bundle** for a single call, where the struct's lifetime is the call's. This is defensible but easy to get wrong later, when someone caches the bundle. ## Making the rule stick On a team this is worth mechanising rather than remembering. A lint rule in CI that (a) rejects a `context.Context` typed field on any struct outside a small allowlist and (b) requires `ctx context.Context` as the first parameter of exported functions catches both halves of the anti-pattern at the point where it is cheapest to fix — before a signature is published and other teams have compiled against it. Review alone will not hold the line, because the failure is invisible at the call site, which is exactly where reviewers spend their attention.