Captive dependencies

A service lives as long as whatever holds a reference to it. When a longer-lived service takes a shorter-lived one in its constructor, the shorter-lived one is captured: it now lives as long as its holder. The case that matters is a singleton that depends on a scoped service.

builder.Services.AddDbContext<ShopDb>();               // scoped
builder.Services.AddSingleton<PriceCache>();            // singleton

public class PriceCache(ShopDb db) { /* ... */ }        // captures ShopDb

A singleton is built once, from the root provider, so its dependencies are resolved from the root too. The ShopDb it receives is not any request's context; it is one created for the root and never disposed until shutdown. Every request that touches PriceCache now shares that one context: its change tracker keeps growing, it returns stale entities, and two requests using it at once throw because a DbContext does not support concurrent operations.

The example extends the model container from the last lesson with constructor dependencies. Orders is scoped, PriceCache is a singleton, and both take Db.

1public class Container2{3    public readonly Dictionary<string, (string Life, string[] Deps)> Regs = new();4    readonly Dictionary<string, string> root = new();5    readonly Dictionary<string, int> count = new();6 7    public Dictionary<string, string> NewScope() => new();8 9    public string Resolve(string name, Dictionary<string, string> scope)10    {11        var (life, deps) = Regs[name];12        if (life == "Singleton") scope = root;            // built from the root13        if (life != "Transient" && scope.TryGetValue(name, out var cached)) return cached;14 15        var parts = deps.Select(d => Resolve(d, scope)).ToList();16        count[name] = count.GetValueOrDefault(name) + 1;17        var made = name + "#" + count[name] + (parts.Count > 0 ? "(" + string.Join(",", parts) + ")" : "");18        if (life != "Transient") scope[name] = made;19        return made;20    }21}22 23public static class Solution24{25    public static List<string> Run()26    {27        var c = new Container();28        c.Regs["Db"] = ("Scoped", new string[0]);29        c.Regs["Orders"] = ("Scoped", new[] { "Db" });30        c.Regs["PriceCache"] = ("Singleton", new[] { "Db" });31 32        var lines = new List<string>();33        for (int request = 1; request <= 3; request++)34        {35            var scope = c.NewScope();36            lines.Add($"request {request}: {c.Resolve("Orders", scope)} {c.Resolve("PriceCache", scope)}");37        }38        return lines;39    }40}

The container can catch it

The default container has two switches. ValidateScopes makes it refuse to build a singleton that needs a scoped service, and refuse to resolve a scoped service (or anything that needs one) from the root provider; the check runs when a service is first resolved. ValidateOnBuild runs the singleton check for every registration when the provider is built, so the app fails at startup instead. The default host turns both on in the Development environment and leaves them off elsewhere, which is why this bug usually surfaces as an exception on a developer's machine rather than as stale data in production. The check follows constructor dependencies through the whole graph, so a transient between the singleton and the scoped service does not hide the problem.

Fixes

• Make the consumer scoped if it holds no state worth sharing.

• Inject IServiceScopeFactory and open a scope for each unit of work:

  public class PriceCache(IServiceScopeFactory scopes)
  {
      public async Task RefreshAsync()
      {
          using var scope = scopes.CreateScope();
          var db = scope.ServiceProvider.GetRequiredService<ShopDb>();
          // ... use db, then the scope disposes it
      }
  }
  

• For EF Core specifically, register AddDbContextFactory<ShopDb>() and inject IDbContextFactory<ShopDb>; each CreateDbContext() returns a context the caller owns and disposes.

The second model replaces the scope factory with a small class and calls Refresh twice.

1public class ScopeFactory2{3    int dbCount;4    public Scope CreateScope() => new Scope(this);5    public string NewDb() => "Db#" + ++dbCount;6}7 8public class Scope : IDisposable9{10    readonly ScopeFactory factory;11    string? db;12    public List<string> Log = new();13    public Scope(ScopeFactory f) => factory = f;14    public string Db => db ??= factory.NewDb();          // scoped: one per scope15    public void Dispose() { if (db != null) Log.Add("disposed " + db); }16}17 18public class PriceCache(ScopeFactory scopes)              // singleton19{20    public List<string> Log = new();21    public void Refresh()22    {23        var scope = scopes.CreateScope();24        using (scope)25        {26            Log.Add("refresh with " + scope.Db + " and again " + scope.Db);27        }28        Log.AddRange(scope.Log);29    }30}31 32public static class Solution33{34    public static List<string> Run()35    {36        var cache = new PriceCache(new ScopeFactory());37        cache.Refresh();38        cache.Refresh();39        return cache.Log;40    }41}

Common mistakes

• Fixing the exception by making ShopDb a singleton too. The error goes away and every request now shares one non-thread-safe context.
• Calling CreateScope() once in the singleton's constructor and keeping it. That is the same capture with an extra step.
• Assuming a transient in the middle makes it safe. A transient held by a singleton lives as long as the singleton, and so does everything it holds.

What interviewers ask

• What is a captive dependency and why is it dangerous with a DbContext? A longer-lived service holding a shorter-lived one; stale tracked entities, unbounded tracking, and concurrent-use exceptions.
• How do you use a scoped service from a singleton or a background service? IServiceScopeFactory.CreateScope() per unit of work, or IDbContextFactory<T>; dispose what you create.
• Why did this throw on your machine but not in production? Scope validation is on in Development by default.