-
-
Notifications
You must be signed in to change notification settings - Fork 74
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
Add API Error handling and local rate-limiting #53
Add API Error handling and local rate-limiting #53
Conversation
Awesome! At a quick glance, don't see any blockers - will poke around tomorrow or this weekend and merge it in. At some point, it might be handy to:
Thanks again, this will be quite handy! |
…ation from the Slack API
(using the Leaky Bucket algorithm)
(to account for clock differences/etc.)
Right - now that
I briefly considered this - however, I'm unsure what would be best here from a usability perspective. Perhaps a config flag to globally disable rate-limiting? |
Alrighty, ran through again, this looks good to me, and no one else has chimed in, merging! Thanks again for taking the time to add this! |
Not sure on specifics. Maybe:
Open to other options though - cheers! |
This PR covers two separate, yet two related issues:
By adding in a basic error-handler on the API - one that handles both 4xx/5xx errors from the API as well as results where
ok
is$false
- we can handle rate-limiting a little better.Local rate-limiting has been implemented behind a switch (
-RateLimit
) onSend-SlackApi
. This uses the Leaky Bucket algorithm to allow for 25 burst requests, with 1 second between requests otherwise. This seems to be very similar to Slack's rate-limit parameters, and will automatically recover from rate-limit errors returned by Slack's API.This PR should resolve #52.