Similar config as this: https://pkg.go.dev/github.com/cenkalti/backoff/v4#WithMaxElapsedTime
The limit of the time that can be spent per request including all retries and delays.
I understand that this goal can be achieved using context timeout, but it's often easier to limit requests to the client on the initialization level instead of passing it to the caller.
The setting itself can conflict with RetryMax, assuming that both of them decide when to stop, but logically I would expect quitting by the first one to reach the boundary. In other words, either maximum retries exceeded, or max backoff time reached the limit.
Similar config as this: https://pkg.go.dev/github.com/cenkalti/backoff/v4#WithMaxElapsedTime The limit of the time that can be spent per request including all retries and delays. I understand that this goal can be achieved using context timeout, but it's often easier to limit requests to the client on the initialization level instead of passing it to the caller. The setting itself can conflict with
RetryMax
, assuming that both of them decide when to stop, but logically I would expect quitting by the first one to reach the boundary. In other words, either maximum retries exceeded, or max backoff time reached the limit.