In RxJS, a view tears down with takeUntil(destroy$), yet its polling keeps firing after it closes; why does takeUntil's position in the pipe matter?

## The symptom A dashboard view refreshes its data every five seconds. It uses the classic pattern: a `destroy$` subject fired when the view is torn down, and `takeUntil(destroy$)` in the pipe. After the view closes, the network panel still shows a request every five seconds, and memory grows each time the view is opened and closed. ```ts import { Subject, switchMap, takeUntil, timer } from 'rxjs'; refresh$.pipe( takeUntil(this.destroy$), // too early switchMap(() => timer(0, 5000).pipe(switchMap(() => load()))), ).subscribe(render); ``` ## Two signals, two directions The bug comes from how RxJS operators pass signals along a chain: - **Unsubscription travels upstream.** Calling `unsubscribe()` on the final `Subscription` walks up through every operator, and each one tears down whatever it subscribed to, **including active inner subscriptions**. - **Completion travels downstream.** A `complete` notification tells each later operator "your source is finished", and each operator decides what that means for itself. `takeUntil` does both, from its own position: when the notifier emits, it unsubscribes from the operators **above** it and sends `complete` to the operators **below** it. ## Why the flattening operator keeps the inner alive The higher-order mapping operators define completion as "the outer source has completed **and** no inner subscription is still active": | Operator after `takeUntil` | What it does on outer `complete` | |---|---| | `switchMap` | keeps the current inner running until it completes | | `mergeMap` | keeps every active inner running | | `concatMap` | finishes the active inner and any queued ones | | `exhaustMap` | keeps the current inner running | | `combineLatestWith(other$)`, `mergeWith(other$)` | wait for `other$` to complete too | An inner `timer(0, 5000)` never completes, so the flattening operator never completes, never unsubscribes it, and the observer at the end of the chain stays referenced. The leak is the inner stream plus everything its closures capture. ## The fix 1. **Move `takeUntil` to the end**, directly before `subscribe()`. Now, when `destroy$` emits, `takeUntil` unsubscribes from `switchMap`, and that unsubscription travels up into the inner `timer`, clearing it. 2. **Or keep the handle.** `const sub = stream$.subscribe(...)` followed by `sub.unsubscribe()` on teardown has no placement rule at all, because unsubscription always propagates up the entire chain. 3. **Make sure the notifier emits.** The pattern relies on calling `destroy$.next()` in the owner's teardown; the exact rules for a notifier that completes without emitting belong to `takeUntil`'s own semantics. ```ts refresh$.pipe( switchMap(() => timer(0, 5000).pipe(switchMap(() => load()))), takeUntil(this.destroy$), // last: tears down the inner too ).subscribe(render); ``` ## Why it survives code review The leaking pipe reads naturally from top to bottom: "stop when destroyed, then poll". Nothing fails, no error is logged, and the visible screen behaves correctly because the leaked inner renders into a view that is no longer attached. The cost only appears as duplicated background requests, rising memory, and callbacks running against destroyed state, sometimes much later, when a leaked callback writes into a service that another screen reads. ## Diagnosing it in a real app - Put **`finalize(() => console.log('poll ended'))`** inside the inner stream. If the message never appears when the view closes, the inner was never unsubscribed. - Open and close the view several times while watching the network panel: one extra polling cadence per visit is the signature of this leak. - Take heap snapshots before and after a few open-close cycles and look for detached view instances retained by subscriber objects. - Review every pipe for **operators that wait on more than one subscription** placed after `takeUntil`: the flattening family and joins such as `combineLatestWith` or `mergeWith`, which complete only when all their sources have. ## When something may legitimately follow takeUntil The rule of thumb is "last", but operators that only react to the notifications they receive and open no subscriptions of their own, such as `finalize`, `map` or `tap`, are safe after it. Operators that keep another subscription alive until it completes are not. Some multi-source operators forward the outer completion and release their other sources, but relying on knowing which ones do is fragile, which is why teams simply keep `takeUntil` last. Lint rules exist in the ecosystem to enforce the placement mechanically, which is worth adopting in a large codebase because the bug is invisible in code review unless you know to look for it. ## The same rule in framework helpers Destroy-bound operators that frameworks provide are built on the same completion mechanism, so they carry the same placement rule: put them last.