Your Go handler writes an audit record from a goroutine and the rows stopped appearing, with context.Canceled logged at the write. What happened?

## Reading the symptom The log line — `context.Canceled` at the audit write — points at the context, and the context in question is the request's. Confirm it by looking at where the goroutine's `ctx` came from: `go writeAudit(r.Context(), rec)` or a closure capturing `r`. Both give the goroutine a context whose lifetime ended when the handler returned. The timing explains the shape of the data loss. Fast requests lose the record almost always; slow ones occasionally get it in, because the goroutine sometimes reaches the database before the handler unwinds. That is why the failure often looks intermittent and correlates with latency rather than with any property of the record. ## Why it fails at all The server cancels the request context on two events: the client going away, and `ServeHTTP` returning. The second is unconditional — a perfectly successful request cancels its context on the way out. `database/sql` honours contexts, so `ExecContext` on an already-cancelled context does not even reach the driver; it returns straight away. Any well-behaved context-aware call behaves the same. ## The direct fix: detach ```go func handler(w http.ResponseWriter, r *http.Request) { rec := buildRecord(r) // copy everything out of r first w.WriteHeader(http.StatusOK) ctx, cancel := context.WithTimeout( context.WithoutCancel(r.Context()), 5*time.Second) go func() { defer cancel() if err := writeAudit(ctx, rec); err != nil { log.Println("audit write failed:", err) } }() } ``` `context.WithoutCancel(parent)` returns a copy of the parent that is **not** cancelled when the parent is: it has no deadline, its `Err()` stays nil and its `Done()` channel is nil, so it blocks forever. What it keeps is the parent's **values** — the request id, the correlation data, whatever your middleware attached — which is exactly why it is better than starting from `context.Background()`. You detach the cancellation without losing the identity of the request. The second half matters as much as the first: a context that can never be cancelled is a context with no bound at all. Wrap it in `context.WithTimeout` so a wedged dependency cannot pin the goroutine forever, and `defer cancel()` so the timer is released. And note the ordering: build the record *before* returning. The request body and the `ResponseWriter` are invalid once the handler returns, so the goroutine must hold copies, not the request. ## Why the direct fix is not the whole answer Detaching makes the write attempt happen. It does not make it reliable: - **The process can exit.** A deploy, a crash, an OOM kill, or a graceful shutdown that waits for handlers but knows nothing about your goroutine, and the record is gone with no trace. `(*http.Server).Shutdown` waits for active requests; a goroutine you spawned is not one. - **It is unbounded.** One goroutine per request means a slow audit database converts a traffic spike into memory pressure and an ever-growing pile of pending writes. - **Failures are invisible unless you count them.** Add a counter for attempted versus completed writes so the next occurrence shows up as a diverging pair of numbers rather than as a data engineer noticing a gap weeks later. If the records are genuinely required — audit, billing, anything someone reconciles — the structurally right answers are to write them **inside** the request, in the same transaction as the business change where possible, or to hand them to a **bounded worker pool fed by a buffered channel** that graceful shutdown drains, or to persist them to durable storage and let a separate consumer do the slow part. Detaching a context is the correct mechanism for best-effort work that should not be paid for on the response's latency budget; it is not a durability mechanism. ## How to prevent the recurrence Make the mistake hard to write. A tiny helper — one that takes the request context, detaches it, applies the house timeout, and submits to the worker pool — means nobody hand-rolls `go f(r.Context())` again. Grep for `go ` statements inside handlers in review; the pattern is easy to spot once you know it. And exercise the path in a test that asserts the record exists *after* the response has been served, since a test that only checks the HTTP status will pass happily while every row is being dropped.