Review a design where a singleton service stores a scoped service or request object. What can go wrong?

In production I treat this as an ownership and concurrency failure, not merely a DI rule. A captive DbContext can retain tracked entities, return stale state, throw concurrent-operation errors, and hold connections or other disposables longer than intended. Captured HttpContext or user data can leak one request's identity into unrelated work. I enable scope validation outside development where practical, review singleton fields and delegates, and inspect heap paths through root service-provider instances, queues, callbacks, and caches when memory rises. The repair defines an operation boundary: create the scope immediately before processing, resolve everything from that scope, await the work, and dispose the scope before taking the next item. Retries create fresh scopes, cancellation reaches the handler, and singleton coordination state remains thread safe and small. Tests process several tenant jobs concurrently and verify separate scoped instances, correct identities, disposal after each item, and no use after cancellation. If work needs request facts later, those facts are validated and copied into a durable command rather than retaining the live request graph.