When a request ends, what must a framework's container do with the components it created in that request's scope?

## What "closing a scope" means A request scope is an instance map plus a record of what was created in it. Closing it is not garbage collection and does not depend on it: it is an explicit, ordered sequence the container performs. 1. Stop serving resolutions from that scope — nothing new may be created in a scope that is closing. 2. Walk the instances created in it that expose a release hook, and invoke each one. 3. Discard the map, so the scope retains no references and whatever it held becomes reclaimable. Only the container-created instances are the container's responsibility. Anything a component constructed by hand inside its own logic is that component's job to release, in its own release hook. ## Ordering and errors - **Reverse construction order** is the norm. Construction order encodes dependency order, so a component built later may hold one built earlier; releasing newest first guarantees nothing is torn down while something still using it is alive. It is the same discipline as unwinding a stack. - **One failure must not abort the sweep.** If a release hook throws, the container should record it and continue with the rest. The alternative leaks every instance after the failing one, and the leak grows with every request that hits the same failure. - **Release should be quick and local.** A hook that makes a network call or blocks on a lock stretches the tail of every request, because it runs on the request's own path. ## When the scope must close | Situation | Correct moment to close | What breaks if you close earlier | |---|---|---| | Ordinary buffered response | After the response is fully written | Nothing — body is already produced | | Streamed or chunked body | After the last chunk is written | The stream reads from components that were already released | | Handler threw, error response sent | After the error response is written | The error path leaks exactly when the system is already unhealthy | | Client disconnected mid-response | As soon as the framework abandons the exchange | Resources stay borrowed for a request nobody is waiting for | The common mistake is closing the scope when the handler **returns**. For a streamed body the handler returns long before the body is finished, so the scope must be tied to the completion of the exchange, not to the handler call. ## The transient-disposal trap A transient component built inside a request scope is released with that scope only if the container tracks disposables **in the scope that created them**. Some containers track them in the longest-lived scope instead, so short-lived objects accumulate for the life of the process even though everything about their registration says "short-lived". It is worth knowing which behaviour your container has before registering anything transient that owns a resource. ## What breaks when disposal is skipped 1. **Pool exhaustion first.** Connections, buffers or permits borrowed per request and never returned run the pool dry after a predictable number of requests. The service looks healthy, then every request blocks on acquisition. This is usually the earliest and clearest symptom. 2. **Locks and open units of work.** A unit of work left open holds its locks, so unrelated requests start timing out on rows they never touched. 3. **Memory growth.** Retained scope maps keep whole object graphs alive. Slower to show than pool exhaustion, and easy to misdiagnose as a memory problem in the application code rather than a lifetime problem in the wiring. 4. **Cross-request leakage.** If a scope's map is retained and later reused, one request can observe another's state, which is a correctness and privacy failure rather than a capacity one. ## What disposal is not for Release hooks are for **giving resources back**, not for doing business work. Committing a unit of work from a release hook is a common and poor design: by the time the scope closes the response is typically committed — the status line and headers are already on the wire — so a failure has no way to be reported to the client. Decide the outcome inside the request, and let the hook only release what was borrowed. ## How to verify it - Drive steady traffic and watch the pool's in-use count return to its baseline between bursts; a monotonic climb is a leak. - Include the failure paths in that traffic. Leaks live disproportionately on the error path, because that is the path with the least test coverage. - Exercise a streamed endpoint specifically, since it is the one case where correct-looking cleanup runs too early.