CodeRigor

LESSON

Carry a server-owned request ID through context

Use a private context key, preserve cancellation and correlate one response without trusting incoming identity claims or creating metric labels.

A request ID links one response to its log event. It is useful context, not a user identity, permission or proof that a request is trustworthy.

This lab always generates server-owned IDs. It does not copy arbitrary incoming X-Request-ID header values into logs. The final middleware places its own value in a response header and a private context key for application code.

One server token links the exchange
start / 3
The server creates an ID, derives the request context and returns the same correlation value in a response header.
One server token links the exchange
The server creates an ID, derives the request context and returns the same correlation value in a response header.

Use an unexported key type so another package’s string request_id value cannot collide. Derive from the supplied parent with context.WithValue rather than starting a new background context.

The identifier’s length/alphabet checks are part of the local format. They cannot prove that arbitrary client text contains no sensitive data; generating server-owned tokens is a separate policy decision.

Go
package main
import ("fmt";"context")
func main(){
type requestKey struct{};parent:=context.Background();child:=context.WithValue(parent,requestKey{},"lab-1");fmt.Println(child.Value(requestKey{}),parent.Value(requestKey{}))
}

Cancellation and deadlines remain attached to the parent request. A context used only to carry an ID should not disconnect that lifecycle.

The local command’s IDs are process-scoped correlation values and can restart when the process restarts. The course does not claim global uniqueness or W3C distributed-trace propagation. Those are a later operational boundary.

Keep IDs in events, not metric labels. Metrics aggregate a closed set of normalized method/route/status groups; logs provide a way to inspect one exemplar. Mixing the two creates unbounded cardinality and makes a tiny metric collector grow with traffic.

Use different dimensions for events and metrics
start / 3
An event can identify one request. A counter groups many requests under bounded labels. Keep those roles separate.
Use different dimensions for events and metrics
An event can identify one request. A counter groups many requests under bounded labels. Keep those roles separate.
Go
package main
import ("fmt";"context")
func main(){
parent,cancel:=context.WithCancel(context.Background());defer cancel();child:=context.WithValue(parent,struct{}{},"lab-2");cancel();fmt.Println(child.Err())
}

Complete the context helper and test private-key separation, exact ID lengths and cancellation. The final middleware supplies the server generator and response header.

Next we serialize only approved event fields and prove that sensitive source fields are omitted.

Watch & read

Free lectures, talks and readings that cover this skill from another angle. All resources →

Optional primary discussion of structured logging and Go’s slog design. This lab uses a small explicit event DTO; the continuation expands into logger configuration, storage and a fuller observability stack.