What is the current behavior?

When producerAccessed creates a new ReactiveLink for a non-live consumer (e.g. a computed signal that has no readers yet), it eagerly sets prevConsumer to the producer's current consumersTail:

const prevConsumerLink = node.consumersTail;
// ...
const newLink = {
  // ...
  prevConsumer: prevConsumerLink,  // captures a pointer INTO the consumer list
};
// ...
if (isLive) {
  producerAddLiveConsumer(node, newLink);  // only called when live
}

Because the consumer is not live, producerAddLiveConsumer is skipped and the link is never inserted into the producer's consumer doubly-linked list. But prevConsumer already holds a reference to a node inside that list.

When that referenced node is later removed from the consumer list via producerRemoveLiveConsumerLink, the doubly-linked list is correctly patched — but the dangling prevConsumer on the non-live link is not patched, because the non-live link isn't part of the list and isn't traversable from it.

The removed link, and everything it retains, is kept alive indefinitely by this dangling reference.

How I found it

I was investigating a memory leak in a large Angular app (~1.5GB heap, other leaks going on too from our side!). After navigating away from a page, 3.3 MB of detached DOM (53+ cu-data-view-item elements, their parent DataViewListComponent, ViewsBarComponent, ViewBlockComponent, etc.) remained alive.

Using heap snapshot retainer analysis, I traced the single retention path:

GC Root
  → Window.logNgrxState (closure)
    → NgZoneStoreService2.store
      → R3Injector.records (Map)
        → AttachmentApiV1Service [providedIn: 'root']
          → urls (computed signal)
            → SIGNAL node [producers linked list]
              → producer link @9563675 (edge: computed reads environmentSignal)
                → prevConsumer → @11501677 (STALE — destroyed view's consumer link)
                  → consumer → ReactiveLViewConsumer @20250859 (destroyed)
                    → view → LView (3.3 MB retained)
                      → ViewsBarComponent → ViewBlockComponent
                        → DataViewListComponent → 53+ detached DOM elements

The key evidence from the heap:

• The ReactiveLViewConsumer's own producers and producersTail are both undefined — confirming consumerDestroy ran and cleaned up the consumer side.
• But the producer link for the urls computed (@9563675) still has prevConsumer pointing to the stale consumer link (@11501677), because the link was never part of the consumer list and was never patched during removal.
• Cutting AttachmentApiV1Service alone eliminated all paths to GC roots (both JS and C++ InternalNode paths), confirming this is the sole retention mechanism.
• The environmentSignal's own active consumer list (consumers/consumersTail) was correctly updated — the stale entry was removed from the active list. Only the dangling prevConsumer on the adjacent non-live link kept it alive.

What is the fix?

Initialize prevConsumer to undefined at link creation time instead of eagerly capturing node.consumersTail.

This is safe because producerAddLiveConsumer unconditionally sets link.prevConsumer = consumersTail when the link is actually inserted into the consumer list. The value set in producerAccessed was always overwritten for live consumers, so it only ever mattered for non-live consumers — where it was always wrong (a dangling pointer into a list the link doesn't belong to).

Does this PR introduce a breaking change?

No. The prevConsumer field set in producerAccessed was dead-on-arrival for live consumers (overwritten by producerAddLiveConsumer) and incorrect for non-live consumers (dangling reference). No code path reads prevConsumer on a link that hasn't been inserted via producerAddLiveConsumer.

I checked the PR where this was added, and it doesn't seem to be commented on that this reference could retain. https://github.com/angular/angular/pull/62284/changes#diff-f1832f2d695da63c1470248ac2005fb2b57549086f0bedf6bc6db00b54bc17f0R260

Noting that I have applied this patch to our internal repo and tested it - the leak is resolved and signals from the root service appear to be functioning correctly.