Feature: Emit something before retry.

[benlesh]

Issue this would address:

Frequently I find myself writing code to dance around the fact that I want to do things like display the number of retry attempts as I'm retrying. Currently, I've just been using a side effect to do that, but it would be nice if I could output the retry attempts or a retry message in to the same output stream.

const retryInfo = new Subject<{ count: number, error: any }>();

source$.pipe(
  retry({
    delay: (error, count) => {
       // log the error so we can see it.
       console.error(error);
       
       // Notify some external observer that there's a retry in progress
       retryInfo.next({ count, error });
       
       // delay the retry by some time
       return timer(5000);
    }
  })
)

The problem with this approach is I've found it's better to mix connection status, or upload progress, or whatever, into the same stream as the output data, and share/filter it appropriately later.

Proposed solution:

Add a configurable/optional function that can be used to select a temporary observable that will be run until the retry commences. This can also be used for synchronous retry. In this case I'm calling it emitOnRetry, but we can bikeshed that name.

declare const source$: Observable<{ type: 'CONNECTING' | 'CONNECTED' | 'UPDATE', payload?: SomeData[]>;

source$.pipe(
  retry({
    emitOnRetry: (error, count) => of({ type: 'RETRY', error, count }),
    delay: (error, count) => {
       // log the error so we can see it.
       console.error(error);
       
       // delay the retry by some time
       return timer(5000);
    }
  })
)

The behavior of the above:

1. When source$ errors, call emitOnRetry, and immediately subscribe to the resulting observable input, flattening results into the resulting observable
2. Then immediately call and subscribe to the result of delay.
3. When the result of delay emits, immediately unsubscribe from the emitOnRetry observable and execute appropriate retry logic.

In the synchronous retry case (when delay is not provided), this wouldn't work any different. If emitOnRetry returned a synchronous source, it would have a chance to emit whatever it was before the sync retry logic fired.

Pros

• This would be a powerful feature to add to the new retry, which is already an improvement over retryWhen and the previous retry.
• The only other way to accomplish this with existing operators before would have been with something like catchError then repeat, but that would not have allowed for access to the retry count.

Cons

• Added surface area may create some additional confusion. Especially around sync retries?

[DanHarman]

would it be bad to expose the observer in delay as a final arg rather than adding another slightly obtuse property to retry?

[benlesh]

I'm not sure I follow.

[josepot]

Personally, I think that this proposal would make the API or retry too complicated and not very intuitive... For instance, it's not obvious when the subscription for the delay observable starts if the emitOnRetry option is also being used... Is it after the observable returned from emitOnRetry has completed? or do they start "at the same time"? And why would I need to use the delay option when I can delay the new subscription of the source through the Observable of emitOnRetry?

I mean, I've read the behavior that you have described, and yes, after reading that, it's reasonable and it makes sense, but it feels a bit arbitrary. Just by having a look at the API that's not the behavior that I would have guessed.

IMHO a cleaner approach would be to pass the count of retries as the 3rd parameter of the selector of catchError:

source$.pipe(
  catchError((err, caught, count) => {
    // log the error so we can see it.
    console.error(error);
       
    // delay the retry by some time
    return timer(5000).pipe(
      concatMapTo(caught),
      startWith({ type: 'RETRY', error, count }),
    )
  })
)

[josepot]

Although, now that I think about it: catchError doesn't have a resetOnSuccess option... 🤔

[robmcm]

What about adding a config parameter to re-throw the error. Then you would be able to use the catchError operator after the retry operator to log/emit another value.

I do also like the original proposal. "Visibility of system status" is an important usability heuristic and currently the retry operator makes it difficult to expose the observable's current state.