Closed chat screens keep receiving pushed messages and memory grows with every open-and-close cycle — how do you diagnose and fix it?

## Read the symptom backwards "Closed screens still receive messages" is not a delivery bug; it is a **lifetime** bug stated in delivery terms. Values only arrive at a subscriber that is still subscribed, so if a destroyed screen is receiving them, its subscription is still live. Every other part of the symptom follows from that one fact: memory grows because each cycle adds one more live subscription, and the per-message cost grows because every one of those subscribers does the work again. ## Why nothing gets released The references point the wrong way for collection: - The **source** is long-lived — a conversation feed that keeps running regardless of who is listening. - The source holds the **subscriber** it was given, because it must, in order to push values to it. - The subscriber is a callback that **closes over the screen** (or its view) so it can append messages. So the chain runs source → subscriber → screen. The screen is unreachable from the application's own structures, and entirely reachable from the source. Nothing can be reclaimed. This is why the leak is invisible in review: the screen code looks correct, the pipeline looks correct, and the missing line is the one nobody wrote. ## Diagnosing it Three checks settle it quickly, in order of cost: 1. **Count starts against ends.** Instrument the subscribe path and the ending path with a counter, exercise the open-and-close cycle a dozen times, and compare. A count of live subscriptions that only rises is the diagnosis; no further evidence is needed. 2. **Follow what holds the destroyed objects.** Inspect the retained objects after a cycle and walk the reference chain back. It will end at the source, through a callback that captured the screen. 3. **Count the deliveries per message.** If one incoming message produces n handlings after n cycles, each cycle left exactly one subscriber behind, which also tells you the leak is per-subscription rather than per-message. The distinguishing feature against other resource growth is the **step shape**: each open-and-close cycle adds one increment and nothing ever returns it. ## Fixing it: give every subscription an owner The fix is not "remember to cancel". Remembering is what already failed. Make disposal structural, so that a subscription cannot outlive the thing that created it: - **Collect the handles.** The screen owns a container; every subscription it starts goes in; destroying the screen cancels everything in the container. One line at the end of the screen's life covers every subscription it ever started, including ones added later by other developers. - **Bind to the owner's end-of-life signal.** Express the screen's destruction as a value on a stream of its own and let each pipeline stop itself when that arrives. The pipeline then ends from the inside, without the screen having to hold handles at all. - **Never let a subscription escape without an owner.** A subscribe call whose handle is discarded is the defect to catch in review. Treat an unowned subscription the way you would treat an opened resource with no matching release. | Approach | Where disposal lives | Fails when | |---|---|---| | Cancel by hand at each call site | Every call site | Anyone adds a subscription and forgets | | Handles collected in an owner-scoped container | One place per owner | The container is not emptied on destruction | | End-of-life signal folded into the pipeline | Inside the pipeline | The signal is never emitted | ## What makes this leak specific to subscriptions Two details are worth naming because they explain why the same code is fine elsewhere. First, the source outlives the subscriber by design: it exists to serve whoever is listening, so it is the long-lived end of the reference chain. Second, the callback is a closure, so the capture is implicit — the developer wrote "append to the view", not "hold the view forever", and the retention is invisible at the call site. A source that finishes on its own tears its subscribers down at completion and hides this class of bug entirely, which is why it only appears once a genuinely long-lived feed is involved. In an interview, say the lifetime rule first — **every subscription has an owner whose end cancels it** — then the reference chain that explains the memory, then the cheap counter check that proves it. A candidate who jumps straight to inspecting retained objects without stating the rule usually fixes the one screen in front of them and leaves the pattern in place everywhere else.