You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I might be wrong, but I think right now we hedge all requests, regardless if idempotent or not which might result in a bug. Shouldnt we check that we only hedge idempotent requests to be safe?
The text was updated successfully, but these errors were encountered:
Hey @MichaHoffmann you are right, cristalhq/hedgedhttp doesn't separate idempotent and non-idempotent requests. And will not 'cause idempotency can be achieved in a different way (header, cookie, url param, etc). Better to leave this responsibility to the user.
Regarding how this can be achived, @GiedriusS is absolutely correct. NextFn 1st return param says how many hedged request should be done, zero is exactly what is should be used for non-idempotent requests.
I will add GUIDE.md file and will document that (I'm shocked that there is no GUIDE.md, almost all other cristalhq libs have it).
I might be wrong, but I think right now we hedge all requests, regardless if idempotent or not which might result in a bug. Shouldnt we check that we only hedge idempotent requests to be safe?
The text was updated successfully, but these errors were encountered: