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

Goal

Determine the exact order in which side‑effect operators execute when an Observable throws an error and catchError supplies a fallback stream.

Constraints

The source Observable emits a sequence, then errors. A tap operator is attached to the source to log or update state. The fallback provided by catchError also contains a tap to record recovery events. All operators run under RxJS 7.x, where retry signatures changed and retryWhen is deprecated.

Uncertainty

RxJS documentation does not explicitly state whether the tap on the original stream fires before the fallback stream begins emitting, or whether the fallback’s side‑effects run in parallel or after the original stream’s completion. This ambiguity impacts stateful operators such as scan or a shared BehaviorSubject that rely on the order of side‑effects.

Questions

• Does the tap attached to the source Observable run before the fallback stream starts emitting?
• When the fallback stream has its own tap, does that side‑effect execute concurrently with or after the source’s side‑effect?
• How does this ordering affect a stateful scan that relies on the source’s emissions versus the fallback’s emissions?