Feature request: shouldRetry option should accept async functions

[BehzadV]

Hello,
My feature request is that it would be better for the retryBackoff operator's shouldRetry option to also accept async functions (Promise).
Let's say that I am calling an API within my operators but every once in a while I get a token error, which is caught within the retryBackoff, visible within the shouldRetry option. I can use this opportunity to obtain a new token and then retry the call. However, I can't since shouldRetry does not accept an async function.

[EugeneHerasymchuk]

it sounds like a bit more complicated logic. Just from curiosity, how would you bring a new token into your source observable?

[BehzadV]

It is a complicated logic. In that system, the token was saved for sharing (It was interacting with an ancient system) in a Redis instance.
But I do find it important to have this featured, don't you? @EugeneHerasymchuk

[EugeneHerasymchuk]

@BehzadV
I think I understand business use-case, but my question was, how technically you will implement a solution, when same source$ ( Observable ) will be retaking a different context during each of the iteration of retryWhen() operator.
As I understand the task, it's not a responsibility of this operator at all.
If you will take a look at the source of this lib, you'll see that it's just a retryWhen with a bit more logic to calculate backoff.
retry and retryWhen are taking the same Observable as a source again and again.
What you are looking for is "run retry / retryWhen with different context each retry".

In my understanding, it should be handled before the retry operator, I would try something like:

of().pipe( 
  mergeMap( () => {
     const newToken = this.getToken();
     return api.callWithToken(newToken).pipe(okay => if (!okay) throw(error))
  }),
  retry || retryBackoff || retryWhen  // it doesn't matter because it's just about conditions when to trigger again. But of course, retryBackoff is a great solution due to the increased timer between retries. 
 ) 

that's the only possible solution that I see because then the retry will trigger execution, and it will run from the start, triggering the function that will get you a new token in case of failing

here is some quick example.

But, let me know if you see a solution when you bring this getToken inside of the retry logic ( with shouldRetry ), I can't come up with a solution like that

[BehzadV]

@EugeneHerasymchuk I think the conversation has gotten overcomplicated, and too specific to my case.

In my opinion, a try ... catch ... block is for handling an exception, and sometimes the handling has to happen asynchronously; the retryBackoff operator can reflect this.