Comparison
Captive dependencyvsLifetime scope
Captive dependency
a long-lived object held a per-request one, and every request after the first got the first request's data.
A component held by another whose lifetime is longer than its own, so it outlives the scope it was meant for. The classic instance is a per-request database context captured by a process-wide service, which then serves stale or cross-tenant data quietly rather than failing. Some containers detect the mismatch and refuse to build the graph; where yours does not, it is a review question every time a scoped thing is injected into a singleton.
Full entry →Lifetime scope
the same registration served one shared instance in one place and a new one per request in another, and that was configuration.
The rule a container uses to decide when to reuse an instance and when to build a fresh one: process-wide, per request or operation, or new every time. It is where most container bugs actually live, because the wrong choice is not a crash — it is state visible across requests, or a connection created per call. Choosing it is a design decision about shared mutable state and should be made deliberately, not defaulted.
Full entry →