It would be great to be able to get information about the error

[Trevoke]

Sometimes we may want to know what the failure was, to log it, or do something particular; right now the retry mechanism swallows everything.

[safwank]

Sorry @Trevoke, just saw this. Are you thinking of logging when the retries exit, or between retries?

[Trevoke]

Well, let's say I'm retrying an http call. If it fails because connection refused, or timeout, or unauthorized, those are things that I might want to know about, and right now I don't really get that.

I could wrap the code I want to retry in a function and do that logic in there, but that might give me way more logging than I would if I had some opportunity to do it in an aggregated fashion through this library.

On Wed, Sep 27, 2017, 03:43 Safwan Kamarrudin notifications@github.com wrote:

Sorry @Trevoke https://github.com/trevoke, just saw this. Are you thinking of logging when the retries exit, or between retries?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/safwank/ElixirRetry/issues/13#issuecomment-332437757, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEJSbN1YkBa3Fktl4EoqvbGIgv8woHuks5smfymgaJpZM4Pd8kq .

[safwank]

I'm not sure I follow. If you want to log the error in an "aggregated" fashion, can't you just wait for the retries to give up and handle it accordingly?

It'd probably help if you could provide pseudo code of what you're trying to achieve.

[florinpatrascu]

@safwank - I did encounter a similar design issue, and this the best workaround I was able to come up with: https://github.com/florinpatrascu/bolt_sips/blob/master/lib/bolt_sips/connection.ex#L33-L46 As per my snippet above, there are situations where waiting for the retry to finish is unnecessary, if the error is known to be irreconcilable .. BTW, thank you for this project!

[safwank]

@Trevoke I'm not sure what kind of solution you have in mind, but I'm going to close this as it's been open for awhile now. Feel free to submit a PR.

[cheerfulstoic]

I've started using the retry library and I've been wanting this same thing. It would be useful to be able to log / IO.puts / whatever at each step of the retry process and even at the end. Whenever I build my own simple retry logic I often will output a log / string which will be something like "HTTP request received #{response.status_code} with body #{response.body} (#{tries_left} tries left)"

So maybe there could just be some options for anonymous functions to be passed in? Something like:

retry_fn = fn error, tries_left -> Logger.warn("...") end
fail_fn = fn error -> Logger.warn("...") end

result = retry with: constant_backoff(100) |> Stream.take(10), on_retry: retry_fn, on_fail: fail_fn do
  ... logic
end

I know that there is after and else, and it seems like the else takes care of the on_fail part, but I don't believe that you can use the else with use Retry.Annotation, so this might be more consistent. Also, when I first started working with it, I thought the else might be more like the on_retry functionality

Actually, now that I've typed that all out, I'm realizing it's a complicated by the fact that you don't always have a specific number of tries but that you sometimes have timeouts. So maybe a tries instead of a tries_left would be better