NgRx Effects stream termination after unhandled API errors

Answer the question first

Place the error‑handling operator inside the mergeMap (or concatMap/switchMap) that performs the API call. The catchError must be applied to the inner observable, not to the outer actions$ stream. Returning a new observable (e.g., of(failureAction) or EMPTY) keeps the effect’s source observable alive, so subsequent actions are still processed.

Why this works

An uncaught error in the inner observable propagates to the outer stream, causing the effect to complete. By catching the error inside the inner pipeline and emitting a value (or nothing), the outer stream receives no completion notification and remains subscribed.

Recommended pattern

1. Use mergeMap (or concatMap if ordering matters) to call the API:

   createEffect(() =>
     this.actions$.pipe(
       ofType(loadData),
       mergeMap(action =>
         this.api.fetch(action.id).pipe(
           map(data => loadDataSuccess({ data })),
           catchError(err =>
             // Log, dispatch a failure action, or silently swallow
             of(loadDataFailure({ error: err }))
           )
         )
       )
     )
   );
   

2. If you need retry logic, place retry (or retryWhen) before catchError:

   mergeMap(action =>
     this.api.fetch(action.id).pipe(
       retry(2),
       map(...),
       catchError(err => of(loadDataFailure({ error: err })))
     )
   )
   

3. Never subscribe manually inside the effect. Manual subscriptions create a separate observable chain that can leak if not unsubscribed.

4. Do not rely on a global error handler that only logs; it must re‑emit an observable so the effect stays alive.

5. Unit‑test the flow: dispatch the action, mock the service to throw, assert a failure action is emitted, then dispatch again and confirm the effect still runs.

One diagnostic detail that could change the recommendation

Does your effect currently use switchMap instead of mergeMap or concatMap? If so, the same pattern applies, but you must be careful that switchMap cancels previous requests – this can affect how you want to recover from errors.

Key takeaways

• Catch errors inside the inner observable pipeline.
• Return an observable (e.g., of or EMPTY) to keep the effect alive.
• Avoid manual subscriptions and global handlers that don’t re‑emit.
• Test the effect’s resilience by simulating failures.