How does RetryAgent work?

[acommodari]

So I want to make use of RetryAgent + signal in my project to retry and endpoint.
An example would be retry an endpoint up to 3 times and have a timeout per request of like 1000ms.
I know undici does not have a traditional timeout like axios for example so we can make use of signal to achieve the same thing

But then I came across this issue #1485

So I was wondering how do the 2 features work together? is it possible to achieve what im asking for? i.e. try endpoint, timeout after 1s, retry again for 2nd and 3rd attempt and finally fail.

Also is it possible to do exponential backoff with retry agent? i see the retry options and retry context but I'm not sure how they interact. Maybe more in-depth examples are needed in the docs?

[metcoder95]

👋
Indeed more in-depth examples in the docs will be really valuable.

To achieve what you are looking for, you can rely merely on the options set for your client/dispatcher to handle the timeout settings. On a timeout, and in combination with the RetryHandler, it will lead to a failure that the handler understands and will react accordingly.

To create an exponential-backoff-based Agent, it's enough to just pass the retry callback when creating the RetryAgent/Handler; the context will pass you the current number of retries and the last timeout applied before the last retry. You can use these heuristics to alter the way the timeout is calculated and indicate to the handler when to move forward (e.g. using the retry count as factor, and the base timeout passed through the settings as base).

[acommodari]

oh okay total timeout is basically headersTimeout + bodyTimeout? i wasn't sure how those worked so I opted for signal instead. Maybe I'll try those if they can give me the results I'm looking for.

Just a question since I haven't worked with this concept before what is a "normal" header timeout? the current descriptions are a bit confusing for me... if I want lets say a 1 second total timeout I'm guessing 500ms + 500ms is not correct right? since headers could return quickly? and most of the time spent is retrieving the body?

[metcoder95]

Yeah, you can count the sum of both as the total timeout, but the distribution is not equal as there are several pieces that moves, e.g as you suggests, is highly possible the headers just takes 10% of the avg time for a request, and the other 90% is the whole body, or other pieces in the middle (specially related with last mile issues).

It is kind of hard to find a good balance, overall is better to measure the latency over time and based your tweaks around the 95th to 99th percentile, as usually those are good candidates for being good values

[acommodari]

In my testing however when I actually try setting these timeouts the results dont seem to make sense 🤔
for example i run a simple test like this

let response;
const start = performance.now(); 
try {
  response = await request(...);
} catch(e) {
  console.log(e)
}
const end = performance.now();
console.log('response time', end-start);

response ? console.log(await response.body.json()) : console.log("no response");

and even if i set bodyTimeout to 1 it never times out 🤔
headersTimeout does work but i cant figure out how the value correlates. it seems a lot shorter than the response time.
signal actually seems to track well with the actual response time but like you mentioned this probably won't work if i combine it with retry handler right?
so im a bit confused on how i should interpret this

[acommodari]

looking at this issue #474 it seems to me then that if i use something like a res.json or res.send that writes headers and the body basically one after the other that the bulk (95%) of the timeout is handled by the headersTimeout? since you wait for the server to finish then set headers and the body right away

[metcoder95]

It can be, its complicated to assess if that percentage is precise, but definitely is something you can measure by your own by using the a dispatcher as measure the time for the headers to arrive; so you can tune your settings based on that.

Using signal can work, but we should be conscious that it might make the retry-handler unusable because the request has been already aborted.

Ideally, I think the RetryHandler is designed to be used for a single request and not reused across requests as it just do retry count and error handling, which are the basics of retry; something more complex and robust like a circuit-breaker might be better suited for usage across requests.