Context forms a tree where cancellation propagates from parent to all children. Every function that may block or do I/O should accept a ctx as its first parameter and respect its cancellation.
Pass context as the first parameter — never store it in a struct
Always call the cancel function returned by WithCancel/WithTimeout — even if the operation completes
Use context.WithValue only for request-scoped metadata (trace IDs, auth tokens) — not for optional parameters
Respect ctx.Done() in goroutines: select on it alongside work channels
Check ctx.Err() to distinguish context.Canceled from context.DeadlineExceeded
You have a worker goroutine reading from a channel. How would you use a Context so the worker stops when the caller cancels?
If you pass a parent context with a timeout into a function that spawns its own goroutine, what happens to that goroutine when the timeout expires?
What will happen if a long‑running loop ignores the context’s Done channel?
After deploying an HTTP handler that launches several downstream goroutines with their own WithCancel contexts, we see goroutines hanging after the client disconnects. Walk me through how you’d debug the cancellation propagation.
In a batch job we wrap the top‑level context with a deadline, but inner functions create child contexts with WithCancel and never defer cancel. Explain the impact on resources and how you’d fix it.
Why might a deeper call receive a nil context value even though the parent passed a non‑nil context, and how does that affect cancellation?
Design a request‑handling pipeline where each stage runs in its own goroutine and must respect client cancellation. How do you structure the contexts to avoid leaks and ensure timely shutdown?
A service forwards a request to multiple downstream services in parallel, each with its own timeout. How would you combine their contexts to propagate a single cancellation signal while still handling individual deadlines?
What are the performance implications of creating many short‑lived contexts in a tight loop, and how would you mitigate any overhead in a latency‑critical path?
We’re migrating legacy code that uses custom cancellation channels to the standard context package. What strategy would you use to introduce Context across services while minimizing disruption and ensuring backward compatibility?
At scale we observed that context cancellation sometimes propagates slower than expected due to blocked goroutine cleanup. How would you redesign the concurrency model or context usage to guarantee prompt cancellation across thousands of goroutines?
When building a cross‑team library for request tracing and cancellation, what conventions would you enforce around context propagation, deadline setting, and value usage to avoid anti‑patterns?