RxJS v7: Timing of side-effects when recovering a stream with catchError

Direct answer

Yes. In source.pipe(tap(...), catchError(() => fallback.pipe(tap(...)))), the source tap's error handler runs before catchError subscribes to the fallback. The fallback's tap side-effects run only when the fallback emits, completes, or errors. RxJS push delivery is sequential per subscription, so these side-effects are not concurrent; the fallback runs after the source error side-effect.

Confirmed mechanics

• catchError intercepts the error notification and does not wait for source completion.
• A tap before catchError sees source emissions and, with an error handler, the source error.
• A tap inside the fallback sees fallback output only, not the original source error.
• A downstream tap after catchError sees recovered emissions, not the source error.
• scan after catchError accumulates source emissions first, then fallback emissions, in delivery order. The error itself is not an accumulator input unless the fallback emits or rethrows it. catchError does not reset scan state.

Verification (RxJS 7.x)

import { of, throwError, concat } from 'rxjs';
import { tap, catchError } from 'rxjs/operators';

concat(of(1, 2), throwError(() => new Error('boom')))
  .pipe(
    tap({
      next: x => console.log('source', x),
      error: e => console.log('source error', e.message),
    }),
    catchError(() =>
      of('recovered').pipe(
        tap({
          next: x => console.log('fallback', x),
          complete: () => console.log('fallback complete'),
        })
      )
    ),
    tap(x => console.log('downstream', x))
  )
  .subscribe();

Expected order: source 1, source 2, source error, fallback recovered, fallback complete, downstream recovered. With an asynchronous fallback such as timer(1000), the fallback logs occur later on the scheduler but still after the synchronous source-error log.

Assumptions and uncertainty

• This assumes standard RxJS 7.x catchError behavior and no custom scheduler delaying the source error itself.
• If the catchError selector throws, or the fallback errors, downstream receives that error and fallback side-effects may not complete.
• Minor patch versions or custom schedulers can change wall-clock timing of asynchronous fallbacks, not the sequential before/after relationship.

Note whether your fallback is synchronous (of) or asynchronous (timer, HTTP request, Subject); this affects wall-clock timing, not the before/after ordering above.