Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue-213: Optional automatic retry on 5xx #214

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Conversation

ewandennis
Copy link
Contributor

@ewandennis ewandennis commented Jul 4, 2017

Addresses #213:

  • Constructor now accepts a numeric retries option which defaults to undefined.
  • By default, no retries are attempted to protect existing tested code paths and compatibility
  • When enabled, each request will be retried until it returns a non 5xx status or until retries attempts are reached.

@aydrian
Copy link
Contributor

aydrian commented Jul 5, 2017

Could you also add a line to the CHANGELOG.md under the "Unreleased" header? Makes it easier for when we do a release.

Otherwise, it LGTM, but maybe could get a second set of eyes. @jasonrhodes, @AymG?

@ewandennis
Copy link
Contributor Author

Incidentally, I'd also welcome discussion on whether this should even exist in our client libs and if so, whether it should be enabled by default (after a suitable version bump).

@avigoldman
Copy link
Contributor

I like this in the libraries personally. The functionality isn't heavy or complicated and it makes the process of using our service a smoother experience.

@jasonrhodes
Copy link
Contributor

I definitely don't like the idea of turning it on by default ever, for the sake of not raising an unwitting fleet of accidental DDoSers esp if we have a spat of 503s or some other DNS error.

Other than that I agree it's a nice feature… maybe think about capping retries at something sane? Maybe 3-5 with some back off logic?

@avigoldman
Copy link
Contributor

I agree, it doesn't make sense to turn it on by default. Having some back off logic does feel good.

@aydrian
Copy link
Contributor

aydrian commented Aug 8, 2017

Any thoughts on @jasonrhodes suggestions, @ewandennis? Do we have this in the php library? Is it handled the same?

@ewandennis
Copy link
Contributor Author

Yup, I submitted a similar feature to php-sparkpost at the time.

As for safety, I can see a reason to enforce an upper retry limit. Back-off also sounds good in theory but, since we already ask people to retry on 5xx without back-off and the world has not ended, I wonder if it's really necessary. Back-off isn't a very intuitive mechanism for the user either so I wonder if we might get all-new questions about API call latency.

@aydrian
Copy link
Contributor

aydrian commented Aug 11, 2017

Awesome. Thank you. @jasonrhodes / @avigoldman Can you take a look? We can merge this in and I'll do a minor release.

@crobinson42
Copy link

Why did this die? This is a great feature to have - my Node.js server gets 503 errors randomly from Sparkpost when trying to send and this is starting to become concerning. An automatic retry would be great to have confidence in the service.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants