Context package a yi aiki don abin ne?

Question

Accepted Answer

The **`context`** package carries **cancellation signals, deadlines, and request-scoped values** across API boundaries and goroutines. It's the standard mechanism for controlling the lifetime of operations — especially for cancelling work and propagating timeouts through a chain of function calls.

## Matsalar asali da ya warware shi

```text
A request starts work across many goroutines/functions (DB query, API call, etc.).
If the client disconnects or a timeout hits, you want to CANCEL all that work
so goroutines don't keep running uselessly (wasting resources / leaking).
→ context propagates the "stop now" signal down the entire call chain.
```

## Sarrafa contexts

```go
ctx := context.Background()          // the root context (top of the tree)
ctx := context.TODO()                 // placeholder when unsure

// with a timeout — auto-cancels after the duration
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()                        // ALWAYS call cancel to release resources

// with manual cancellation
ctx, cancel := context.WithCancel(context.Background())
// call cancel() to signal cancellation

// with a deadline (specific time)
ctx, cancel := context.WithDeadline(ctx, time.Now().Add(time.Minute))
```

`WithTimeout`/`WithDeadline`/`WithCancel` derive a child context that can be cancelled; you must `defer cancel()` to free its resources.

## Amsa ga soke (cancellation)

```go
func doWork(ctx context.Context) error {
    for {
        select {
        case <-ctx.Done():            // fires when cancelled or timed out
            return ctx.Err()           // returns context.Canceled or DeadlineExceeded
        case work := <-jobs:
            process(work)
        }
    }
}
```

Functions check `ctx.Done()` (a channel that closes on cancellation) and stop promptly — this is how cancellation actually propagates.

## Wada context ta fili cikin jerin kira (al'ada)

```go
// ctx is conventionally the FIRST parameter, named ctx
func handler(ctx context.Context, ...) {
    data, err := fetchFromDB(ctx, id)   // pass it down — DB call honors cancellation
}
func fetchFromDB(ctx context.Context, id int) (...) {
    row := db.QueryRowContext(ctx, ...)  // standard-library APIs accept context
}
```

Context flows down the call stack as the first parameter, so cancellation reaches every layer (including standard-library DB/HTTP calls that accept a context).

## Ƙimun request-scoped values (yi amfani da ƙarfi)

```go
ctx = context.WithValue(ctx, requestIDKey, "abc-123")   // attach a value
id := ctx.Value(requestIDKey)                            // retrieve it downstream
// ⚠️ for request-scoped metadata (request IDs, auth) — NOT for passing regular params
```

## Me ya sa ya mahalaci

The `context` package is fundamental to writing robust, production-grade Go services — it's the standard, idiomatic way to handle **cancellation and timeouts** across goroutines and API boundaries.

Its primary value is preventing wasted work and resource leaks: when a client disconnects, a deadline passes, or a server shuts down, context propagates the cancellation signal so all the goroutines and operations spawned for that request stop promptly rather than running uselessly (a key defense against goroutine leaks).

It's pervasive in real Go — HTTP servers, database calls, gRPC, and most networked libraries accept a `context.Context` as their first parameter.

Understanding how to create contexts (`WithTimeout`/`WithCancel`), respond to cancellation (`<-ctx.Done()`), the must-call-`cancel()` rule, and the convention of threading context through call chains is essential for any serious Go backend work and a common interview topic.