Toast: TypeError reading '_lView' when multiple toasts close (NgForOf + splice by index + detectChanges)

[busvar]

Describe the bug

When multiple p-toast messages are open and their leave animations finish close together, Angular throws:

TypeError: Cannot read properties of null (reading '_lView')

This is reported via Sentry in production. The toast UI still appears, but the exception is thrown during close.

Environment

• Angular: 21.2.x
• PrimeNG: 21.1.9
• Also checked current master toast source — same pattern still present

Stack (relevant frames)

ToastItem.onAfterLeave → Toast.onMessageClose → messages.splice(event.index, 1) → this.cd.detectChanges() → NgForOf.ngDoCheck / _applyChanges → ViewContainerRef.get(...) → null → ViewContainerRef.move(null, ...) → insertImpl → viewRef._lView // crash
Full path goes through @primeuix/motion leave callback → ToastItem.onAfterLeave → Toast.onMessageClose.

Root cause (analysis)

In toast.ts:

1. Items are rendered with *ngFor="let msg of messages; let i = index" (no trackBy / @for track).
2. On close, onMessageClose removes with messages.splice(event.index, 1) using a numeric index from the child.
3. It then calls this.cd.detectChanges() synchronously from the leave-animation callback.

If two leave animations complete nearly at the same time, the second close can use a stale index. That desyncs the messages array from the ViewContainerRef views. NgForOf._applyChanges then does move(null) and Angular crashes on null._lView.

This is easier to hit when the same error toast is added twice quickly (e.g. double submit), then both auto-dismiss.

Expected behavior

Closing multiple toasts (including overlapping leave animations) should not throw.

Suggested fix

1. Remove by message identity, not index, e.g.
   this.messages = this.messages?.filter(m => m !== event.message) ?? null
2. Prefer @for (msg of messages; track msg) (or assign a stable id on add() and track that).
3. Prefer markForCheck() instead of forced detectChanges() inside onAfterLeave / onMessageClose.

[cagataycivici]

v22 has a brand new Toast component, v21 is only supported for security updates. Can you confirm if a similar issue happens in v22 Toast as well?

[busvar]

Unfortunately, I can’t confirm this on v22. v21 is the last version under the MIT license, and we only use MIT-licensed dependencies in our project, so we can’t move to / test against v22.

From our side the bug is still present in 21.1.9, and the same *ngFor + splice(event.index) + detectChanges() pattern is what we hit in production (Sentry stack above). If that close path was rewritten in the new v22 Toast, it may already be fixed there — we just can’t verify it ourselves.