Should a shared failure-body factory take the correlation id as a parameter or read it from request-scoped context?

Every failure body in the contract carries a correlation id, and the shared factory is what stamps it. The design question is how the factory *obtains* it: as an argument every caller supplies, or as an ambient value bound to the current request that the factory reads for itself. ## Judge the options by what they demand of call sites | Property | Id passed as a parameter | Id read from request-scoped context | |---|---|---| | Can a call site omit it? | Yes, by passing a placeholder or the wrong value | No - the call site is not involved | | Effect on intermediate code | The id must be threaded through signatures that have no other use for it | None | | Behaviour when work leaves the request's execution unit | Still correct, because the value travelled with the call | Empty unless the framework propagates the context | | Testability | Trivial - pass a fixed value | Needs the context populated, or an injectable reader | Threading the id as a parameter is not wrong, and in a small, strictly synchronous codebase it is honest and obvious. But it reintroduces the failure mode the shared factory was built to eliminate: a discipline that every author must observe at every call site. Intermediate functions that care nothing about correlation ids start carrying one because something beneath them might raise a failure. That is a smell, and it is how parameters get defaulted to empty strings 'just for now'. ## Ambient context, precisely 'Request-scoped context' means a value bound to the unit of work handling this request and readable without being passed - typically by the framework's own request context, or by a mechanism that associates state with the executing thread, task or coroutine. The property it provides is that code arbitrarily deep in a call chain can read a value that was set once at the edge, without the intervening frames knowing it exists. That property is what the factory needs, and it comes with one structural caveat: **the binding is to an execution unit, not to the universe.** Frameworks differ here - some propagate the context automatically across their own asynchronous boundaries, others require the value to be captured and restored explicitly when work is handed to another executor. Either way, the assumption 'a correlation id is always present' is exactly the kind of quantifier that turns into a production incident. ## The two rules the factory must follow 1. **Never generate an id at write time.** If the context is empty and the factory quietly creates a fresh identifier, the body looks perfect and is worthless: the value the client quotes in a support ticket appears in no log record, because every log line for that request was written with whatever the request actually carried, or with nothing. A fabricated id is worse than a missing one, because it survives inspection. 2. **Degrade on purpose, and loudly.** Define the behaviour for an empty context up front - omit the field entirely, or emit a clearly marked value - and log a warning at that point so the gap is visible in monitoring instead of only in a confused support conversation. What the factory must not do is throw: raising an exception while building a failure response replaces a usable error with an unusable one, and the second failure has no id either. ## The id as untrusted input If the id can be seeded from an inbound request header so that a caller's trace continues through your service, then it is client-controlled text that you are about to put in a response body and in log records. Constrain it before it is accepted into the context: a length cap and a restricted character set. Otherwise the body becomes a vehicle for whatever a caller chose to send, and the log line becomes a place where a caller can inject structure. Validating at the point the context is populated - not in the factory - keeps the rule in one place too. Concretely, before an inbound value is accepted: - **cap its length**, so a caller cannot inflate every log line and every failure body; - **restrict the character set** to something like alphanumerics and separators, so the value cannot carry structure into a log record or markup into a rendered payload; - **generate your own** when the inbound value is missing or rejected, rather than leaving the request without an id; - **record which branch fired**, so a spike of rejected inbound ids is visible rather than silent. ## How to keep it testable Ambient state is harder to test than a parameter, and the usual answer is a narrow seam: the factory depends on a small reader abstraction with one operation - give me the current correlation id, if any - which is backed by the framework's context in production and by a fixed value in tests. That keeps the call sites free of the parameter while leaving the factory's behaviour, including its empty-context path, directly testable. ## What a strong answer sounds like Ambient read, because the factory's purpose is to remove per-call-site discipline; never fabricate; define and log the missing-context path; validate the id if it can arrive from outside; and keep a seam so the two interesting paths - present and absent - are both covered by tests.