context-lifecycle

Context Lifecycle Review

Use this skill to catch async work that accidentally captures a short-lived caller context.

The failure mode is subtle: ctx is usually the nearest variable, so a goroutine, timer, callback, or actor handoff may inherit an RPC/test/request context even though the work must continue after that caller returns. When the caller exits, the context is cancelled and the background work can silently stop too early.

Core Question

For every asynchronous handoff, ask:

Who owns this work, and when should it stop?

The answer determines which context is correct.

Search

Start with targeted searches instead of reading whole packages:

rg -n 'go func|AfterFunc|time\.AfterFunc|context\.AfterFunc' \
  --glob '*.go' [path]

rg -n 'Done\(|WithCancel\(|WithTimeout\(|WithDeadline\(' \
  --glob '*.go' [path]

rg -n '\.Tell\(|\.Ask\(|Register|Subscribe' \
  --glob '*.go' [path]

Then inspect each hit in context.

Classify The Owner

Classify each async handoff before suggesting a fix.

Caller-Owned Work

The caller waits for the goroutine before returning, or the goroutine only performs request-scoped work.

Using the caller context is usually correct.

Examples:

• a goroutine joined by WaitGroup.Wait before return
• a worker that sends one result and the function waits on that result
• a helper that should abort when the RPC deadline expires

Component-Owned Work

The work is started by a caller but owned by a daemon, wallet, actor, or service after startup.

Do not capture the RPC/request context. Use a component root context, a registration-owned context, or an explicit context with its own cancel path.

Examples:

• wallet sync loops started by UnlockWallet
• daemon background workers started from an RPC
• actor goroutines started during actor construction
• server connection runtimes started by daemon setup

Registration-Owned Work

The work forwards notifications until an explicit returned Cancel, Stop, or subscription teardown is invoked.