1stop := context.AfterFunc(ctx, func() {
2    // cleanup logic here
3    conn.Close()
4})
5
6// Call stop() if you want to prevent the function from running
7defer stop()

This is cleaner than spinning up a goroutine with select on ctx.Done() – the stdlib handles the lifecycle for you.

Key things to note:

• The function runs in its own goroutine
• stop() returns true if it successfully prevented the call
• Multiple AfterFunc calls on the same context are independent

dbtpl (part of the xo ecosystem) connects to a database, introspects the schema, and generates type-safe structs and query methods through Go templates. Hand-written DB structs easily drift from the schema; dbtpl makes the schema the single source of truth.

Explanation

How it works

Database (PostgreSQL / MySQL / SQLite...)
    ↓ introspect schema (tables, columns, types, indexes, FK...)
dbtpl
    ↓ apply Go templates
Generated Go code (structs, query methods)

No need to maintain DB structs by hand – when the schema changes, re-run dbtpl to sync.

Two modes

Schema mode: generate from the entire DB schema

1dbtpl schema postgres://user:pass@host/dbname -o ./models

Generates a Go struct for each table, including methods related to primary keys, foreign keys, and indexes.

Query mode: generate type-safe result structs from custom SQL

1dbtpl query postgres://user:pass@host/dbname << ENDSQL
2SELECT a.name::varchar AS name, b.type::integer AS my_type
3FROM authors a
4JOIN authortypes b ON a.id = b.author_id
5WHERE a.id = %%authorID int%%
6ENDSQL

%%param type%% is dbtpl’s query parameter syntax, which generates a corresponding function signature.

What gets generated

• Go structs matching each table (field types aligned with DB schema)
• CRUD query methods (Insert, Update, Delete, Get by PK)
• Enum types
• Struct tags (db:"column_name" etc.)

Template customization

dbtpl’s generation logic uses Go text/template. You can dump the built-in templates and modify them:

1dbtpl dump --src base -o ./custom-templates
2# edit the .tpl files in custom-templates/
3dbtpl schema postgres://... --src ./custom-templates

Knowledge Sugar

Why not just hand-write structs?

dbtpl vs sqlc

Both generate Go code from a database, but they differ in approach:

• sqlc: SQL-query-centric – write SQL first, then generate the corresponding functions
• dbtpl: schema-centric – introspects the entire DB, with more template flexibility

Go’s context is the standard solution for propagating cancellation signals, timeouts, and request-scoped data across goroutines. It lets an entire call chain stop cleanly at a unified point, leaving no goroutine leaks.

Explanation

The problem

An HTTP handler often runs multiple goroutines underneath – hitting the DB, calling external APIs, doing computation. Three scenarios cause trouble:

1. Timeout: the request times out, and downstream work should stop too
2. Cancellation: the user closes the browser mid-request; continuing is wasted work
3. Request-scoped data: auth tokens and trace IDs need to flow down the call chain without adding a parameter to every function

context unifies all three into a single standard interface.

Basic usage

1ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
2defer cancel() // must call this, otherwise it leaks resources
3
4result, err := db.QueryContext(ctx, "SELECT ...")

When the timeout expires, ctx.Done() closes, and all context-aware functions stop automatically.

How to receive it in a function

Functions that accept a context take ctx context.Context as the first parameter – this is a mandatory Go convention.

1func doWork(ctx context.Context) error {
2    select {
3    case <-ctx.Done():
4        return ctx.Err() // context.DeadlineExceeded or context.Canceled
5    case result := <-longOperation():
6        return process(result)
7    }
8}

Four ways to create a context

Every new context is a child of its parent – cancellation only propagates from parent to child. When the parent is cancelled, all children are cancelled too.

Knowledge Sugar

Context must not be stored in a struct

Always pass it as a parameter, never put it in a struct field.

A context represents the lifetime of a request, not object state. Storing it in a struct makes the lifetime unclear.

WithValue is only for cross-cutting concerns

WithValue is for things like tracing IDs and auth tokens – data every request needs but that would pollute function signatures. Do not use it to pass regular business parameters – for those, just add a proper parameter.

Mental model

Context is a control signal for a tree. When the root says “stop,” every goroutine in the tree stops – cleanly, no leaks.

A shallow copy copies the “reference to the data” – the original and the copy still share the underlying data. A deep copy copies “the data itself” – the two are completely independent. Go’s assignment is shallow copy by default; whether the original is affected depends on whether the type is a value type or a reference type.

Explanation

Value type vs Reference type

Slice: the most common gotcha

1a := []int{1, 2, 3}
2b := a          // shallow copy: b and a share the same underlying array
3
4b[0] = 99
5fmt.Println(a)  // [99 2 3]  <- a was modified!

a → [ header: ptr → [99, 2, 3], len=3, cap=3 ]
b → [ header: ptr ↗ ]   ← same array

To deep copy a slice, use copy():

1c := make([]int, len(a))
2copy(c, a)      // deep copy
3
4c[0] = 0
5fmt.Println(a)  // [99 2 3]  <- a is not affected

Map: assignment also only copies the reference

 1m1 := map[string]int{"a": 1}
 2m2 := m1        // shallow copy
 3
 4m2["a"] = 99
 5fmt.Println(m1["a"])  // 99 <- m1 was also modified
 6
 7// deep copy a map by looping manually
 8m3 := make(map[string]int)
 9for k, v := range m1 {
10    m3[k] = v
11}

Struct: value copy by default, but watch out for pointer/slice fields

 1type Person struct {
 2    Name   string
 3    Scores []int   // slice is a reference type!
 4}
 5
 6p1 := Person{Name: "Alice", Scores: []int{90, 80}}
 7p2 := p1           // struct is value-copied, but Scores only copies the slice header
 8
 9p2.Name = "Bob"
10fmt.Println(p1.Name)      // "Alice" <- string is a value type, not affected
11
12p2.Scores[0] = 100
13fmt.Println(p1.Scores[0]) // 100 <- the underlying array of Scores is shared!

To deep copy a struct with slices, explicitly copy each reference field:

1p3 := Person{
2    Name:   p1.Name,
3    Scores: make([]int, len(p1.Scores)),
4}
5copy(p3.Scores, p1.Scores)

copy() limitation: only copies the outer layer

copy() is a built-in function, but it only copies element values – it does not recursively handle nested reference types.

 1// Elements are value type → copy() works as a deep copy
 2a := []int{1, 2, 3}
 3b := make([]int, len(a))
 4copy(b, a)  // fully independent, no problem
 5
 6// Elements are reference type → copy() only copies the outer layer, inner layer is still shared
 7a := [][]int{{1, 2}, {3, 4}}
 8b := make([][]int, len(a))
 9copy(b, a)  // b[0] and a[0] still point to the same underlying array!
10
11b[0][0] = 99
12fmt.Println(a[0][0])  // 99 <- still modified

Conclusion: copy() is sufficient when elements are value types; when elements contain reference types, you need to copy recursively by hand.

Knowledge Sugar

Go has no built-in deep copy

For complex nested structures, there is no silver bullet. Common approaches:

Interview essential: the underlying structure of slice assignment

A Go slice is essentially a struct:

1// Conceptually looks like this (not actual Go code)
2type SliceHeader struct {
3    Data uintptr  // pointer to the underlying array
4    Len  int
5    Cap  int
6}

b := a copies this header, not the underlying array – that is the root cause of shallow copy.

One-sentence test

If modifying the copy also changes the original, it is a shallow copy. If not, it is a deep copy.

When multiple goroutines share a value that gets updated periodically (like an auth token), use atomic.Value for lock-free reads and writes – lighter than a mutex. Combined with time.Ticker for periodic refresh and ctx.Done() for goroutine lifecycle control, this forms a complete concurrent token management pattern.

Explanation

The problem

10 goroutines publish events concurrently, each needing an AUTHZ token. Another goroutine refreshes the token every 40s (TTL 60s, refreshing 20s early as buffer).

How do you let the refresher (writer) and 10 publishers (readers) safely share the same token without a data race?

atomic.Value: lock-free shared value

1var token atomic.Value  // declared, zero value is nil
2
3// Write (refresher goroutine)
4token.Store("new-token-string")
5
6// Read (publisher goroutines, can read concurrently, no lock needed)
7t := token.Load().(string)  // type assertion to get the actual type

atomic.Value’s Store/Load are atomic operations – no mutex needed. Multiple goroutines reading concurrently is completely safe, and an occasional Store will not give any reader a corrupted value.

Complete pattern

 1var token atomic.Value
 2
 3// Refresher goroutine: periodically refresh the token
 4go func() {
 5    ticker := time.NewTicker(40 * time.Second)
 6    defer ticker.Stop()  // remember to release ticker resources
 7
 8    for {
 9        select {
10        case <-ticker.C:
11            newToken, err := fetchToken(ctx)
12            if err == nil {
13                token.Store(newToken)
14            }
15        case <-ctx.Done():
16            return  // exit when context is cancelled
17        }
18    }
19}()
20
21// Publisher goroutines: 10 running concurrently
22for i := 0; i < 10; i++ {
23    go func() {
24        for {
25            select {
26            case event := <-eventCh:
27                t := token.Load().(string)  // read current token
28                publish(ctx, t, event)
29            case <-ctx.Done():
30                return  // exit when context is cancelled
31            }
32        }
33    }()
34}

time.Ticker: periodically firing channel

1ticker := time.NewTicker(40 * time.Second)
2// ticker.C is a channel that receives a signal every 40s
3// must call ticker.Stop() to release the underlying timer resources
4defer ticker.Stop()

ctx.Done(): unified exit signal

ctx.Done() returns a channel that gets closed when the context is cancelled. All goroutines listening on it in a select will receive the signal and exit simultaneously.

1select {
2case <-ticker.C:
3    // periodic refresh
4case <-ctx.Done():
5    return  // stop when told to, no goroutine leak
6}

Knowledge Sugar

sync.Mutex: a lock to protect critical sections

When multiple goroutines read and write the same data, a mutex ensures only one goroutine can enter at a time:

 1var mu sync.Mutex
 2var sharedData map[string]int
 3
 4// Write
 5mu.Lock()
 6sharedData["key"] = 42
 7mu.Unlock()
 8
 9// Read (also needs lock because map is not concurrent-safe)
10mu.Lock()
11v := sharedData["key"]
12mu.Unlock()
13
14// Idiomatic: defer unlock to avoid forgetting or leaking on panic
15mu.Lock()
16defer mu.Unlock()
17sharedData["key"] = 42

sync.RWMutex is the upgraded version – allows multiple goroutines to read simultaneously (RLock), but writing is exclusive (Lock):

 1var mu sync.RWMutex
 2
 3// Multiple goroutines can hold RLock simultaneously
 4mu.RLock()
 5v := sharedData["key"]
 6mu.RUnlock()
 7
 8// Write is exclusive
 9mu.Lock()
10sharedData["key"] = 99
11mu.Unlock()

Why atomic.Value instead of mutex?

The token scenario: writes are rare (once every 40s), reads are frequent (10 goroutines on every publish) – atomic.Value is the better choice.

What makes atomic operations work?

“Atomic” means indivisible – the operation appears to others as either completed or not started, never “halfway done.”

A normal assignment token = newToken may compile to multiple machine instructions. On a multi-core CPU, another core might read in the middle and get a half-written value (data race).

Atomic operations use special CPU instructions (like x86’s CMPXCHG) to guarantee at the hardware level:

1. Indivisibility: Store is fully written before it becomes visible to other cores
2. Memory visibility: adds a memory barrier, ensuring all cores see the latest value instead of getting stuck on a CPU cache

Normal assignment: Core A writes halfway → Core B might read a corrupted value
Atomic:            Core A finishes writing before it is visible → Core B always sees a complete value

This is why atomic.Value is safe without a mutex – the guarantee is made at the CPU instruction level, not through software locks.

Why refresh every 40s with a 60s TTL?

The 20s buffer absorbs:

• Network latency when fetching the new token
• The time gap before all goroutines read the new token

If you wait until 59s to refresh, any slight delay could cause publishers to send requests with an expired token.

Common cause of goroutine leaks

If a goroutine has no exit mechanism, it runs until the process ends. ctx.Done() is the standard exit signal – once the context is cancelled, all listening goroutines exit cleanly.

Each request produces exactly one log entry, handled by middleware. Errors are only wrapped at boundaries with third-party code. Logging follows the OpenTelemetry standard so logs can plug into any observability backend.

Explanation

Four core principles

1. Every request gets exactly one log

Instead of logging in every handler or function, middleware outputs a single structured log entry when the request completes, containing status code, latency, request ID, and other fields. This avoids scattered log entries for the same request that are hard to correlate.

2. Log should be wrapped in a proper way

Logs should be structured (structured logging) – not fmt.Println("error:", err), but a format with fields:

1{
2  "level": "error",
3  "request_id": "abc-123",
4  "method": "POST",
5  "path": "/orders",
6  "latency_ms": 42,
7  "error": "calling payment sdk: connection refused"
8}

3. Only wrap errors on boundaries with 3rd party code

A boundary is the seam between your code and a system you do not own – calling a DB, calling a third-party SDK, calling an external API are all boundaries.

Errors from third parties lack your context, so wrap once at the boundary. Between internal functions, just pass the error up.

Given the chain: Handler -> getOrder() -> queryOrderFromDB():

 1// Layer 3: DB boundary, the only place to wrap
 2func queryOrderFromDB(ctx context.Context, id int) (*Order, error) {
 3    row, err := db.Query(ctx, "SELECT * FROM orders WHERE id = ?", id)
 4    if err != nil {
 5        // Wrap at the boundary, describe what operation was happening
 6        return nil, fmt.Errorf("querying order id=%d: %w", id, err)
 7    }
 8    // ...
 9}
10
11// Layer 2: internal function, pass up directly, do not re-wrap
12func getOrder(ctx context.Context, id int) (*Order, error) {
13    order, err := queryOrderFromDB(ctx, id)
14    if err != nil {
15        // Just return, no new wrap
16        return nil, err
17    }
18    return order, nil
19}
20
21// Layer 1: handler, also does not wrap -- let middleware handle the log
22func handleGetOrder(w http.ResponseWriter, r *http.Request) {
23    order, err := getOrder(r.Context(), id)
24    if err != nil {
25        // Hand off to middleware, do not log here
26        http.Error(w, "internal error", http.StatusInternalServerError)
27        return
28    }
29    // ...
30}

If every layer wraps, the error message becomes:

handleGetOrder: getOrder: queryOrderFromDB: querying order id=42: connection refused

The repeated function names add no new information – just noise.

Wrapping only at the boundary is much clearer:

querying order id=42: connection refused

The rule: wrap = add new information. No new information, just return err.

4. OTEL compliant logging in middleware

OTEL = OpenTelemetry, the CNCF observability standard that defines a unified format and API for traces, metrics, and logs.

When middleware outputs OTEL-compliant logs, you can plug into any backend (Grafana, Datadog, GCP Cloud Logging) without changing application code.

Request → Middleware (start timer, inject trace context)
           ↓
         Handler (process logic, pass errors up)
           ↓
         Middleware (at the end, log one entry with status / latency / error)

Knowledge Sugar

Why not let each handler log on its own?

Problems with scattered logging:

• The same request might get logged multiple times across functions – hard to correlate
• Inconsistent formats – hard to filter with queries
• Duplicate logs – more noise, higher cost

Middleware-centralized logging means: one request = one log entry = one trace. Searching and debugging become much more intuitive.

Error wrap decision guide

Generics (Go 1.18+) let you write type-parameterized functions – the type is determined at call time, but type checking happens at compile time. This gives you both flexibility and safety.

Explanation

Without Generics vs with Generics

 1// Without generics: same logic duplicated for each type
 2func sumInts(nums []int) int {
 3    var total int
 4    for _, n := range nums { total += n }
 5    return total
 6}
 7func sumFloats(nums []float64) float64 {
 8    var total float64
 9    for _, n := range nums { total += n }
10    return total
11}
12
13// Or use any, but lose type safety -- errors only show up at runtime
14func sumAny(nums []any) any { ... }
15
16// With generics: one function, compile-time type safety
17func sum[T int | float64](nums []T) T {
18    var total T
19    for _, n := range nums { total += n }
20    return total
21}
22
23sum([]int{1, 2, 3})       // T = int
24sum([]float64{1.1, 2.2})  // T = float64

Syntax breakdown

1func ptr[T any](v T) *T { return &v }
2//       ^^^^^^  ^ ^
3//       |       | return type is also T
4//       |       parameter type is T
5//       type parameter: T is the name, any is the constraint

• T – type parameter name, convention is a single uppercase letter
• any – constraint, meaning T can be any type

Constraints can be narrowed

1// Only accept numbers
2func sum[T int | float64](nums []T) T { ... }
3
4// Only accept types that implement String()
5func print[T fmt.Stringer](v T) { ... }

Type inference: usually no need to specify explicitly

1ptr("hello")         // inferred: T = string
2ptr[string]("hello") // explicit, same result

Knowledge Sugar

Generics vs any vs interface

When to use Generics? When the same logic needs to work across multiple types and you want compile-time type error detection. Pointer helpers and collection operations (map, filter, reduce) are the most common examples.

Go 1.22+ introduced several language-level changes. go fix can automatically upgrade old patterns to modern ones: loop variable capture, interface{} to any, and inline pointer helper functions can all be removed or simplified.

Explanation

1. Remove unnecessary loop variable captures

Before Go 1.22, the for loop variable was shared across all iterations at the same memory address. Closures captured the same variable, causing a classic bug:

 1// Before Go 1.22: all goroutines print the same value (the last one)
 2for _, v := range items {
 3    go func() { fmt.Println(v) }()
 4}
 5
 6// Old workaround: redeclare inside the loop to force a new variable
 7for _, v := range items {
 8    v := v  // capture a new variable per iteration
 9    go func() { fmt.Println(v) }()
10}

Starting from Go 1.22, each iteration has an independent variable, making v := v redundant. go fix removes it automatically.

2. Replace interface{} with any

Go 1.18 introduced any as a type alias for interface{}. They are identical, but any is shorter:

1// Old
2func process(v interface{}) {}
3var m map[string]interface{}
4
5// New
6func process(v any) {}
7var m map[string]any

3. Remove inline pointer helper functions

Taking a pointer to a literal used to require a helper function (because Go does not allow &"hello" directly):

1// Old workaround
2func strPtr(s string) *string { return &s }
3func intPtr(i int) *int { return &i }
4
5name := strPtr("Alice")
6age  := intPtr(30)

Modern Go can replace all type-specific helpers with a single generic version, or just declare a variable and take its address:

1// One generic helper replaces all
2func ptr[T any](v T) *T { return &v }
3
4// Or just declare and reference
5name := "Alice"
6req.Name = &name

What is a literal?

A literal is a fixed value written directly in code – not a variable, not a computed result, just the value as written:

1"hello"        // string literal
242             // integer literal
3true           // boolean literal
4[]int{1, 2, 3} // slice literal

Go does not allow taking a pointer to a literal (&"hello" is a compile error) because literals have no memory address. You must assign to a variable first – that is why pointer helper functions existed.

For details on generics, see the Go Generics post.

Knowledge Sugar

What is go fix?

go fix is an official Go refactoring tool that applies mechanical fixes for each version’s breaking changes or language updates. Running it once when upgrading saves a lot of manual edits.

1go fix ./...

Why is the Go 1.22 loop variable change important?

This bug existed for over ten years and was one of Go’s most famous gotchas – nearly every Go developer hit it at least once. Go 1.22 changed the behavior to match intuition, which is a significant language-level fix.

Marshal converts an in-memory data structure into a transmittable format (like JSON). Unmarshal does the reverse – it turns JSON back into a data structure. Most APIs use JSON because it is human-readable, natively supported by JavaScript, and universally available across languages.

Explanation

Marshal / Unmarshal

 1type ShippingClass struct {
 2    Name string `json:"name"`
 3    Lang string `json:"lang"`
 4}
 5
 6// Unmarshal: JSON string → struct
 7jsonStr := `{"name": "標準配送", "lang": "zh"}`
 8var obj ShippingClass
 9json.Unmarshal([]byte(jsonStr), &obj)
10// obj.Name == "標準配送"
11
12// Marshal: struct → JSON string
13data, _ := json.Marshal(obj)
14// data == {"name":"標準配送","lang":"zh"}

This is not limited to JSON – serialization for XML, YAML, and protobuf is also called marshal/unmarshal. Same concept, different formats.

Why do most APIs use JSON?

• Human-readable: you can read it directly when debugging; binary formats like protobuf cannot do this
• Native JS support: browsers parse JSON at zero cost, no extra handling on the frontend
• Universal: almost every language has a mature JSON library
• Less verbose than XML: XML’s opening and closing tags add a lot of overhead

Knowledge Sugar

What are Go struct tags?

The json:"name" tag tells Go’s JSON library which key name this field maps to in JSON. Without a tag, it defaults to the field name (case-sensitive):

1type Example struct {
2    DisplayName string `json:"display_name"`  // JSON key is display_name
3    Age         int    `json:"age,omitempty"` // omitempty: omit this key when value is zero
4    Internal    string `json:"-"`             // never output to JSON
5}

Downsides of JSON

JSON is not without problems. In high-performance scenarios (internal microservice communication), protobuf is the usual choice:

Fetching private Go modules directly from GitHub in CI/CD easily gets rate-limited (403) when there are too many requests. The fix is to set GOPROXY in your CD yaml to point at an internal Athens proxy server – Athens caches the modules, so subsequent builds never hit GitHub again.

CI / go build
      |
   Athens (internal proxy, with cache)
      | (only on first fetch)
   GitHub / VCS

Explanation

Go has three environment variables that control how modules are fetched:

GOPROXY fallback chain

GOPROXY supports comma-separated sources – Go tries them in order:

GOPROXY=https://internal-proxy.company.com,direct

direct is not another proxy – it means fetching directly from VCS (GitHub). If the internal proxy doesn’t have a particular public module, it falls back to direct.

Knowledge Sugar

Why can’t private modules be sent to sum.golang.org? sum.golang.org is a public service. By default, Go sends the module path there for checksum verification. If a private module’s path gets sent, it leaks internal repo information. Use GONOSUMDB or GOPRIVATE to exclude them.

GOPRIVATE vs setting GOPROXY + GONOSUMDB separately GOPRIVATE=company.com/* is equivalent to setting both GONOSUMDB=company.com/* and GONOPROXY=company.com/* (skip proxy, go straight to VCS). If you’re using an internal Athens proxy, you usually still need to explicitly set GOPROXY, because GOPRIVATE tells Go “don’t use a proxy” – which would bypass your Athens instance and hit GitHub directly.

How to pass a GitHub token in Docker builds? If your Dockerfile runs go build and needs to fetch private modules, don’t use ARG for the token – ARG values end up in the build history and can be recovered from image layers even after the file is deleted.

The correct approach is Docker BuildKit’s secret mount:

1RUN --mount=type=secret,id=github_token \
2    GITHUB_TOKEN=$(cat /run/secrets/github_token) \
3    go build ./...

The secret is only visible during this RUN step and is never written to any image layer.

An optional external call should not share a cancellable context – if that call errors and triggers cancel, the entire context is cancelled, affecting operations that shouldn’t be impacted.

Explanation

Scenario from a PR review:

 1// ❌ Problematic version
 2func (s *Service) GetCampaign(ctx context.Context) (*Campaign, error) {
 3    ctx, cancel := context.WithCancel(ctx)
 4    defer cancel()
 5
 6    // campaign components are optional
 7    components, err := s.client.FetchComponents(ctx)
 8    if err != nil {
 9        return nil, err  // defer cancel() fires here, ctx is cancelled
10    }
11
12    // all subsequent operations using the same ctx are affected
13    result, err := s.doSomethingElse(ctx)
14    ...
15}

The problem: FetchComponents fails -> returns error -> defer cancel() executes -> this ctx is cancelled. If this ctx is shared elsewhere, everything blows up together.

Since campaign components are optional, the correct approach is to absorb the error from this call and not propagate it upward:

 1// ✅ Correct version: optional call errors don't affect the main flow
 2func (s *Service) GetCampaign(ctx context.Context) (*Campaign, error) {
 3    // don't create a cancel context here
 4
 5    components, err := s.client.FetchComponents(ctx)
 6    if err != nil {
 7        // optional -- log and continue, don't return error
 8        log.Warn("failed to fetch optional components", "err", err)
 9        components = nil
10    }
11
12    result, err := s.doSomethingElse(ctx)
13    ...
14}

Knowledge Sugar

Context cancellation propagation direction

Cancellation only propagates from parent to child, never in reverse. However, cancel() directly cancels the ctx you created – if other code also holds a reference to this ctx (or child contexts derived from it), they all get cancelled together.

If you need to fully isolate an optional call (unaffected by parent cancellation)

Go 1.21+ has context.WithoutCancel():

1// create a ctx that doesn't inherit the parent's cancel signal
2detachedCtx := context.WithoutCancel(ctx)
3components, err := s.client.FetchComponents(detachedCtx)

This way, even if the parent request is cancelled (e.g. client disconnects), this optional call still runs to completion.

When to use which approach: