In a framework's component container, how can a singleton reach the per-request component of the request in flight?

## Why a plain reference cannot work A component with the process-wide lifetime is constructed once. Whatever it is handed at that moment it keeps forever. A per-request component, by definition, is only correct for the one request it was created in. So the two cannot be connected by an ordinary field: there is no moment at construction time at which "the current request's instance" is a meaningful value for all future requests. Everything that works therefore shares one property: **the identity of the request-scoped object is decided when the call happens, not when the holder is built.** ## Mechanism 1 — pass it in as a parameter The handler runs inside the request scope, so it can resolve the request-scoped component itself and pass what the collaborator needs as a method argument. - The dependency is visible in the signature, so nobody has to know the container exists to read the code. - The collaborator becomes a plain object in tests: no scope to open, no container to configure. - The cost is signature churn — if the value is needed five layers down, five signatures grow. ## Mechanism 2 — inject a factory or accessor The singleton holds a small object whose single job is to return the current scope's instance on demand, and it calls that on every use. - Resolution is explicit and visible at the call site, which makes the lifetime relationship obvious in review. - It works at any depth without threading a parameter through intermediate layers. - It couples the component to a container-shaped abstraction, so tests must supply a stand-in accessor. - It is the form most lifetime validators accept as the sanctioned escape hatch from the longer-holds-shorter rule. ## Mechanism 3 — inject a scope proxy The container injects an object that implements the same interface as the request-scoped component but holds no state of its own. Each call is forwarded to whatever instance the active scope currently holds. - Callers are untouched: the singleton's constructor still declares the dependency it wants, and the wiring looks ordinary. - That invisibility is also the drawback. Nothing at the call site says the resolution is happening per call, and a reader who assumes an ordinary reference will reason about the code incorrectly. - It normally requires the dependency to be an interface or otherwise substitutable, and it adds an indirection on every call. ## Comparing them | Mechanism | Dependency visible at the call site | Works deep in the call stack | Test setup | Main risk | |---|---|---|---|---| | Method parameter | Yes, in the signature | Only by threading it through | None | Signature churn across layers | | Factory or accessor | Yes, at each use | Yes | Stand-in accessor | An extra abstraction to understand | | Scope proxy | No | Yes | Active scope or stand-in | Hidden per-call resolution and hidden failure modes | ## When no scope is active Any late-resolving mechanism has a case with no answer: a call made when no request scope is open. The honest behaviour is an explicit failure that names the problem. The tempting alternatives are all worse: - Creating a detached instance produces work that belongs to no request and silently succeeds. - Returning empty or default values turns a wiring mistake into wrong output somewhere further downstream. - Reusing the most recently closed scope's instance reintroduces exactly the cross-request leakage that scoping exists to prevent. ## What not to do - **Do not stash the request-scoped object in a process-wide mutable field** for the singleton to read. Concurrent requests then overwrite each other, and the failure is timing-dependent and rare enough to survive testing for months. - **Do not inject the container itself** and resolve from it wherever convenient. The dependency disappears from the constructor, every test needs a configured container, and the component can now reach anything at all — the object graph stops being reviewable. - **Do not promote the request-scoped component to the longer lifetime** to make the error go away. That deletes the scoping rather than satisfying it, and the state that made it request-scoped is now shared by every caller. ## Choosing in practice Prefer passing the value in whenever the need is shallow — it is the only option that leaves the collaborator ignorant of scopes entirely. Use an accessor when the need is deep and you want the per-call resolution to be visible. Reserve the proxy for cases where you cannot change the consuming code, and document it, because the whole point of a proxy is that the code does not show what it is doing.