Bug tracking for Angular — session replay, console + HAR (2026)
3 min read · TypeScript
What Angular teams ship with BugMojo
Angular 19 (with Signals, standalone components, and the new control-flow syntax `@if`/`@for`/`@switch`) is a different framework than Angular 14 — but most production Angular bugs in 2026 still trace back to one of three sources: change detection running too often, RxJS subscriptions never cleaning up, or NgZone confusion around async work. Each shows up as performance regressions or memory leaks rather than visible UI errors.
A useful Angular bug report includes the component selector, the change-detection strategy, and the open subscriptions at the moment of failure. BugMojo captures the DOM + console + network HAR — the console part is critical, because Angular's development build is loud with diagnostics that point straight at the root cause.
This guide walks through the most common Angular 19 bug classes, how to capture them, and how to wire BugMojo into an Angular team's Jira workflow.
Angular gotchas
Framework-specific failure modes our team has shipped through. Each one is hard to spot in a screenshot — easy to spot in a session replay.
Signals + OnPush still need explicit reads
High impactA signal read in a template auto-tracks. A signal read inside a method called from a non-template context (like an HTTP interceptor) does NOT. Bug: components with `ChangeDetectionStrategy.OnPush` go stale even though the signal updated.
Standalone components silently bypass NgModule
Medium impactMixing standalone components with NgModule-based ones requires importing providers in two places. A missing provider in standalone bootstrap is a runtime error, not a compile error.
RxJS subscriptions in ngOnInit must be torn down
High impactCalling `.subscribe()` without storing the subscription leaks memory and causes ghost UI updates on later route changes. Use `takeUntilDestroyed()` (Angular 16+) or pipe through an async pipe in the template.
ExpressionChangedAfterItHasBeenCheckedError in dev only
Medium impactAngular's dev mode runs change detection twice; production runs it once. A bug that appears in dev but not prod is usually a Promise.resolve() inside ngAfterViewInit. The error name is intimidating but the fix is almost always `Promise.resolve().then(() => {...})`.
Common Angular bugs
Real bug patterns from Angular apps, with the symptom you’ll see in a bug report and the fix that actually works.
@for without trackBy re-creates DOM on every update
- Symptom
- List of items flickers / loses focus on every data update.
- Fix
- The new `@for` control flow REQUIRES `track` (no longer optional). Provide a stable key.
@for (user of users; track user.id) {
<user-card [user]="user" />
}HTTP interceptor runs outside NgZone
- Symptom
- A request succeeds, you call `set()` on a signal, but the UI never updates.
- Fix
- Run the signal update inside NgZone, OR avoid runOutsideAngular calls that bleed into your code path.
Module-level Provider not picked up by lazy route
- Symptom
- A service is null when a lazy-loaded component tries to inject it.
- Fix
- Providers must be in `providedIn: "root"` or in the route's `providers` array. Lazy routes don't inherit the parent module's providers.
Setup
# Install BugMojo from the Chrome Web Store — works with all Angular versionsBugMojo vs alternatives
The honest comparison — where BugMojo wins, and where another tool might serve you better.
| Capability | BugMojo | Augury / Angular DevTools |
|---|---|---|
| Replay the bug for a teammate | ✅ | ❌ |
| Capture change-detection cycles | ⚠️ (via console) | ✅ live profiler |
| Network HAR + console capture | ✅ | ⚠️ live only |
| Wired to Jira/Linear | ✅ one-click | ❌ |
Frequently asked questions
Sources
- Angular Signals guide — angular.dev (2025)