Production engineering
Reveal answer and reasoning
A robust bounded worker can assign each admitted item a completion owner, create and dispose an operation scope around its work, and signal success only after required cleanup. Request cancellation and host shutdown should resolve or fail that ownership explicitly. If accepted work must survive a crash, store it durably with a recoverable claim/acknowledgment protocol; an in-memory Channel and graceful stop budget cannot supply that requirement.
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.
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.
What a strong answer covers
- A robust bounded worker can assign each admitted item a completion owner, create and dispose an operation scope around its work, and signal success only after required cleanup.
- A full queue can reject admission with429, and a canceled request has a different result from a completed operation.
- The useful evidence joins operation results with independently observed scope lifetime.
Common pitfall
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.
Follow-up questions
- Why would replacing a scoped dependency with a singleton merely to avoid disposal change correctness rather than just allocation cost?
- What race would appear if the TaskCompletionSource were signaled before the operation scope was disposed?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.