Scoped dependencies in an actual hosted worker

30 min guided lesson · Read, predict, then run

External .NET10 SDK10.0.403. Real Kestrel, Microsoft.Data.Sqlite10.0.14 and HybridCache10.11.0. This Development-only owned-loopback fixture exposes deliberate fault controls; it is not a production deployment.

Read or download the complete SDK project, then follow its setup on your computer. The separate C# companion practice below runs in SharpRune’s .NET 9 console environment.

Define the ownership and result contract

A hosted worker outlives an individual request, so retaining a request-scoped dependency inside it can cross the wrong lifetime boundary. The actual worker in this project receives IServiceScopeFactory and creates a new async scope for each accepted item. Its result becomes successful only after that scope has been disposed. This makes disposal an observable part of the completion contract rather than an assumption based on a handler returning. The bounded queue is still ordinary process memory, and the worker's lifetime is still tied to its host. Correct scope ownership does not create persistent jobs or make every dependency safe for arbitrary concurrent use.

Trace the portable .NET9 console companion

The portable .NET9 console program creates an Owned object in each of two loop iterations. A using declaration inside the loop body disposes that iteration's object before the next iteration begins. Constructor accounting assigns IDs one and two and increments Live; idempotent Dispose decrements Live and increments Disposed once. The output is scope:1, scope:2, live:0 and disposed:2. These are real IDisposable calls over ordinary objects, with serialized counters. The program runs no dependency-injection container, background service or channel. Its purpose is deterministic ownership reasoning, while actual framework scopes are exercised only by the external project.

using System;
using System.Linq;
using System.Collections.Generic;
using System.Globalization;
using System.Text;
using System.Text.Json;
using System.Threading;
using System.Threading.Tasks;

for(int i=0;i<2;i++) { using var item=new Owned(); Console.WriteLine("scope:"+item.Id); }
Console.WriteLine("live:"+Owned.Live); Console.WriteLine("disposed:"+Owned.Disposed);
sealed class Owned:IDisposable { private static int next; public static int Live; public static int Disposed; private bool disposed; public int Id {get;}=++next; public Owned(){Live++;} public void Dispose(){if(disposed)return;disposed=true;Live--;Disposed++;} }

Walk through the actual external framework lab

WorkQueue contains a bounded Channel with capacity four, and /worker admits values from one through ten using TryWrite. ScopedWorker reads accepted items, links host and request cancellation and creates an async scope through CreateAsyncScope. It resolves ScopedOperation inside that scope, awaits the processing result, exits the await-using scope and only then completes the item's TaskCompletionSource. ScopeEvidence tracks created, disposed and live instances independently. Two sequential requests containing three and four therefore return six and eight with distinct scope identifiers, while the settled evidence reports two created, two disposed and zero live. The actual processing delay is an implementation detail, not a timing promise.

Keep failure and trust boundaries explicit

A full queue can reject admission with429, and a canceled request has a different result from a completed operation. Completing a channel during shutdown gives accepted work an opportunity to finish within the host's stop budget, but a crash can bypass that opportunity entirely. The example's processing function is tightly bounded and its scopes are not shared between items. This does not justify using a context or another scoped dependency concurrently merely because it came from DI. Queue bounds, request cancellation, per-item failure handling and durable acknowledgment must each have their own owner when extending the worker beyond its classroom behavior.

Practice one: observe the real contract

Practice one: start a fresh fixture, send values three and four sequentially to /worker and record both receipts. Then inspect /worker/evidence after both requests complete. Hint: test distinct scope IDs and created/disposed/live counts separately from the doubled values. A correct number alone would not prove that a scope was released or that a singleton dependency was avoided. Keep the sequential ordering so the expected IDs remain easy to inspect. This exercise relies on the actual async scope ending before the completion signal, rather than a guessed delay after the HTTP response.

Practice two: test another boundary

Practice two: cancel a bounded waiting request and distinguish the client's cancellation from any already accepted item and its scope cleanup. Hint: wait for evidence to settle before classifying a live count, and do not treat a missing response as proof that work never ran. For a design extension, define a per-item error result, host-shutdown behavior and what storage would own accepted work after a process crash. Preserve the rule that a successful completion signal follows required cleanup. Avoid adding an unbounded fire-and-forget path that loses the very ownership boundary being tested.

Interpret the evidence and defend the tradeoffs

The useful evidence joins operation results with independently observed scope lifetime. It shows actual DI creation and disposal for this worker, while the portable counter program explains the simpler lifecycle invariant. A senior answer also separates admission, execution, cancellation, cleanup and acknowledgment, since success at one stage does not prove success at all of them. The fixture establishes neither durable delivery nor thread safety of unrelated services. Its practical lesson is a clear operation owner inside a long-lived service, with a completion boundary strong enough for callers to know which required cleanup has already happened.