There are different reasons why you would want to retry a stream. It's easier to imagine why you would want to if your stream is dealing with AJAX calls. Network connections may be unreliable at times with the local network you are on, or the service you are trying to hit may be temporarily down for some reason. Regardless of the reason, you have a situation where hitting that endpoint will some of the time reply with an answer, and some of the time return a 401 error. What we are describing here is the business case for adding retry logic to your streams. Let's have a look at a stream designed to fail:

// error-handling/error-retry.js
const Rx = require("rxjs/Rx");

let stream$ = Rx.Observable.create(observer => {
  observer.next(1);
  observer.error("err");
})
.retry(3);

// emits 1 1 1 1 err
stream$
  .subscribe(data => console.log(data));

The output of the code above is the value 1 being emitted four times, followed by our error. What happens is that our streams' values are retried three times before the error callback is hit in the subscribe. Using the retry() operator delays when the error is actually treated as an error. The preceding example doesn't make sense to retry, though, as the error will always occur. Therefore, let's take a better example – an AJAX call where the network connection may come and go:

// example of using a retry with AJAX

let ajaxStream$ = Rx.Observable.ajax("UK1.json")
  .map(r => r.response)
  .retry(3);

ajaxStream$.subscribe(
  data => console.log("ajax result", data),
  err => console.error("ajax error", err)
);

Here, we are attempting an AJAX request towards a file that doesn't seem to exist. Having a look at the console, we are faced with the following result:

What we see in the above logging are four failed AJAX requests that lead to an error. We have essentially just switched our simple stream to a more credible AJAX request stream, with the same behavior. Should the file suddenly start to exist, we may have a scenario with two failed attempts and one successful attempt. Our approach has a flaw, though: we retry our AJAX attempts far too often. If we are actually dealing with an intermittent network connection, we need to have some kind of delay between attempts. It is reasonable to set a delay between attempts of at least 30 seconds or more. We can accomplish that by using a slightly different retry operator that takes milliseconds rather than a number of attempts as an argument. It looks like the following:

// retry with a delay

let ajaxStream$ = Rx.Observable.ajax("UK1.json")
  .do(r => console.log("emitted"))
  .map(r => r.response)
  .retryWhen(err => {
    return err.delay(3000);
  });

What we do here is use the operator retryWhen(). The retryWhen() operator's mission in life is to return a stream. At this point, you can manipulate the stream it returns by appending a .delay() operator that takes a number of milliseconds. The result from doing so is that it will retry the AJAX call for all eternity, which may not be what you want.