Effect stops listening after service error in NgRx Effects integration test

The Solution

To simulate a service error without killing the outer actions stream, the fake gateway must return an observable that emits an error—typically via throwError(() => new Error('...'))—and the Effect must handle this error inside the flattening operator (e.g., switchMap, mergeMap, or exhaustMap).

The Observable Shape

The fake gateway should return a cold observable that terminates with an error notification. In a mock service, this is implemented as:

// Fake Gateway Implementation
getDetails(id: string) {
  return throwError(() => new Error('API_FAILURE'));
}

Implementation Logic

The critical requirement is the placement of the catchError operator. If catchError is placed on the main actions$.pipe(...) chain, the error propagates to the root stream, completing it and stopping the Effect from listening to any further actions.

The correct pattern isolates the failure to the inner observable:

this.actions$.pipe(
  ofType(ApiActions.loadData),
  switchMap(action => 
    this.gatewayService.call().pipe(
      map(data => ApiActions.loadSuccess({ data })),
      // Catch error HERE to keep the outer stream alive
      catchError(error => of(ApiActions.loadFailure({ error: error.message })))
    )
  )
)

Verification Strategy

The test should assert both the immediate failure and the continued viability of the stream. This prevents "silent" stream deaths that only appear in production.

1. Dispatch Failure: Trigger the action that causes the fake gateway to throw an error. Assert that the loadFailure action is emitted.
2. Dispatch Recovery: Immediately dispatch a second action (or the same action with a mocked success response). Assert that the loadSuccess action is emitted.

Retry Policy and Delegation

Retry logic should be implemented inside the inner operator chain, preceding the catchError. This ensures that transient failures are handled before the Effect gives up and dispatches a failure action to the store. Delegating retry to a caller is generally avoided in NgRx, as the Effect is intended to encapsulate the side-effect orchestration.

Assumptions and Diagnostics

This solution assumes the use of NgRx 12+ and RxJS 6/7. If the Effect still stops listening despite the inner catchError, please provide the full operator chain of the Effect, as an misplaced filter or takeUntil may be causing premature completion.