Let's talk retries

[Katherine Cox-Buday]

roger peppe <roger.peppe at canonical.com> writes:
> There's a fourth way that you haven't mentioned, which fits somewhere
> in between 1 and 2 I think (it was the first explicit general retry
> code in Juju AFAIK), which is utils.Attempt.
>
> I'd suggest that the way it's used matches the pattern you'd like to
> write quite well:
>
>      for attempt := strategy.State(); attempt.Next(); { Do something }

Thanks, Roger, I had missed that one. utils.Attempt would be my next preference, but it would have to be taught how to be interruptable via channel. I also feel that because so much of Go is oriented towards channels, exposing the wait via a channel rather than a function makes sense, but I don't immediately have a use-case in mind.

>
> AFAIR this pattern was arrived at after some discussion between myself
> and Gustavo. At the time I was thinking of some kind of callback-based
> scheme like the others schemes you mention, but I think that leaving
> the caller in control and the loop explicit is actually nicer - the
> logic is clear to the reader and more composable with other primitives
> (it is also a good match for the pattern you propose).

I strongly agree with this. In my estimation, favoring composability and inline code is much clearer and maintainable than piling one abstractions on another.

> How about making AttemptStrategy a little more flexible?

It looks like we've standardized on juju/retry. I don't have the historical context in my cache to know why we've rewritten retries 3 times now o.0

-- 
Katherine