Asynchronous resource leaks

Treat each acquired resource as an obligation. Name the owner, the operations that may borrow it, and the transition that releases it. A connection handler may own its stream while a pending write borrows a buffer; a timeout task may borrow the handler but must not keep it alive after termination. Transfer ownership explicitly when placing work into a queue. Returning an error to the request owner does not automatically discharge obligations held by background operations.

Use counts together with state: active requests, open descriptors, pending tasks, registered timers, and bytes retained in queues. Rising counts under rising concurrency can be legitimate; counts that remain after all admitted work has ended deserve investigation. Pool capacity and allocator caches can also retain memory intentionally. Compare a quiet baseline with the same quiet state after repeated load cycles, and keep a small inventory of resource identities so a graph of total memory does not become your only evidence.

Requesting cancellation is a control signal, not proof that a task has exited. Cooperative cleanup may need another scheduling turn, and some operations can complete despite a cancellation race. Keep resources alive until the API guarantees that no pending operation can access them. Conversely, do not wait forever for a task that has lost every path to completion. Give shutdown stages deadlines, record unresolved ownership, and choose an explicit final escalation policy appropriate to the process.

Structured task scopes make the joining boundary visible: a parent retains responsibility for children and observes their completion or failure before leaving the scope. Put release logic on success, exception, and cancellation paths, and preserve the runtime's cancellation contract after cleanup. Observe background task failures rather than allowing them to disappear. In Python streams, initiating closure and awaiting its completion are distinct operations. This example illustrates lifecycle separation; other runtimes may expose different completion or reclamation guarantees.

A shutdown protocol can stop admission, notify producers, drain or reject queued work, request cancellation where needed, join owned tasks, complete stream closure, unregister callbacks, and release final buffers. The exact order follows dependencies: a consumer cannot drain if you destroyed its required service first. Define quiescence in observable terms, such as no owned tasks and no open request connections, while documenting intentional process-wide resources. An idle event loop alone proves neither that resources were released nor that remote work stopped.

Inject faults before registration, after queue insertion, during a partial operation, and during cleanup. Repeat the workload and verify return to the declared baseline. In the queue lab, press Reset, set arrival rate to 4 and service rate to 3, predict growth, then press Play. For a separate release-dominant comparison, press Reset again, explicitly set arrival rate to 2 and service rate to 3, predict draining, then press Play. Both runs start with four abstract items rather than carrying a previous backlog forward. The fluid model illustrates conservation pressure only; it does not model task ownership, garbage collection, cancellation races, or prove that your implementation is leak-free.