Executing retry bound to RetryHandler instance instead of retryOpts

[mikaelkaron]

At the moment the retry handler is executed bound to retryOpts. This prevents access to instance variables and methods on the RetryHandler instance, and I'm wondering if simply doing:

    this.retryOpts.retry.call(
      this,
      err,
      {
        state: { counter: this.retryCount++, currentTimeout: this.retryAfter },
        opts: { retryOptions: this.retryOpts, ...this.opts }
      },
      onRetry.bind(this)
    )

Would be an acceptable solution to this.

[metcoder95]

👋
That's the intention, to hide internals of the RetryHandler itself; but curious what's the use case you are looking to enable?

[mikaelkaron]

Om writing an interceptor to do digest auth and wanted the headers from the retry and a simple way to pass them to dispatch. I solved it with a closure, so don’t have an active use-case right now but figured I’d check in to see if the bound context was intentional.

Is there another recommended way to pass data from the retry method other than a custom closure? The only problem I have with it is that it prevents me from reusing the RetryHandler across requests.

[metcoder95]

The RetryHandler is designed to be bound to a single request, as it is not made as a reliability mechanism but rather a flow control one in the case of a bad response.
Though, is maybe something worth it to explore as I've seen few request for them lately.

Maybe something that can be extended in a form of an agent, similar to what has been done for RetryAgent:

undici/lib/dispatcher/retry-agent.js

Line 6 in ef25209

class RetryAgent extends Dispatcher {