Lectures

Let’s break down how to properly manage the lifetime of operations in Go via context.Context: why a context is a “tree” of requests, when to choose context.WithCancel, context.WithTimeout, and context.WithDeadline, how to read Done()/ Err()/ Deadline(), why you should always write defer cancel(), and which mistakes most often lead to “forever” requests and stuck goroutines.

We go through practical rules for working with context.Context in Go: why you shouldn’t turn ctx into a “parameter backpack”, why storing business data via ctx.Value is dangerous, why you shouldn’t keep context inside long-lived struct values, how to correctly pass cancellation/deadlines through layers (HTTP → service → repo), and what data is acceptable in context (metadata like "request_id").

We break down how to use context.WithValue correctly: what it’s for (only request-scoped metadata), why it’s dangerous to turn it into a “parameter warehouse,” and how to make keys type-safe instead of string keys. We’ll build a neat API via WithRequestID/ RequestID, show an example of HTTP middleware and logging with request_id, and also collect anti-patterns and common mistakes.

We break down why and how to propagate ctx through all layers of a Go application: from the operation boundary ( r.Context() in HTTP or context.Background() in CLI) down to app/service and storage. We show where to place context.WithTimeout, why it is important to do defer cancel(), and how to correctly react to cancellation via ctx.Done() / ctx.Err()—using the example training app Tasker and CSV import.

We break down why “just run N goroutines” is not enough, and how to combine several parallel subtasks into one managed operation: waiting via sync.WaitGroup, cancellation via context.WithCancel, returning the “first error” via a buffered errCh and a non-blocking send, and also collecting all errors via errors.Join. Separately, we discuss cancel() discipline, respecting ctx.Done(), and common concurrency pitfalls.