Clojurians Log v2

clj-https retry handler doesn't retry on 400s, it's only called on IOException type errors (socket timeouts and such). IIRC, even when you set :throw-exceptions true the retry handler won't be called. Depending on your needs, you can hook into the client builder and supply your own implementation of the retry strategy interface

yeah, got it. I would prefer to define retry strategies on client builder than to use an external macro or https://github.com/sunng87/diehard or https://github.com/BrunoBonacci/safely

what do you prefer? @lukaszkorecki?

Yeah, same - I've created an internal http client, which wraps clj-http and integrated it with https://github.com/potetm/fusebox to handle retries and such

:http-builder-fns
             [(fn [builder req]
                (clj-http.core/add-retry-handler builder (fn [e cnt context]
                                                             (def _e e))))]

Hm, I did it differently - the wrapper ensures that clj-http never throws on 500 status and below. Then it uses Fusebox to decide when to retry a request, based on the response, or type of exception - basically, it allows retries for 'bad' HTTP statuses, and if an exception is thrown it doesn't retry and re-throws the exception as that's in our case an unrecoverable error. Unfortunately I cannot easily share the code, it's quite specific to my team's setup in quite a few places.

yeah yeah no worriess

got to ask if I was in the right direction only

thanks @lukaszkorecki 😄

https://github.com/dakrone/clj-http/blob/5a5288319abab50141b8785625feca8de5a11dfc/src/clj_http/core.clj#L282

I'll take a look on it's usages and go beyond

I'll be revising the retry layer soon actually, so might report back - I contributed changes to Fusebox recently and adopting them would simplify some things, so I'll look into this part as well

thanks 😄