https://api.slack.com/docs/rate-limits#events_api
I've been hit by slack rate limits (and not even doing that many calls.. they've become much more stringent with that recently). When that happens we get back http 429, which slack-web forwards to the caller, and there is a HTTP header: Retry-After: <number of seconds>.
I think that maybe slack-web should optionally handle that for the user. I can maybe try to make a PR, when I get some time, but we'd need to agree as to how to do implement that.
Do we add a new option to all existing calls RateLimitHandling = RateLimitFail | RateLimitWaitAndResend? Do we do it automatically out of the box, without any way to disable it (in which case there is no API change)? Or do we consider slack-web is the wrong layer in the stack to deal with that, and we change nothing compared to the current situation?
https://api.slack.com/docs/rate-limits#events_api
I've been hit by slack rate limits (and not even doing that many calls.. they've become much more stringent with that recently). When that happens we get back http 429, which slack-web forwards to the caller, and there is a HTTP header:
Retry-After: <number of seconds>.I think that maybe slack-web should optionally handle that for the user. I can maybe try to make a PR, when I get some time, but we'd need to agree as to how to do implement that.
Do we add a new option to all existing calls
RateLimitHandling = RateLimitFail | RateLimitWaitAndResend? Do we do it automatically out of the box, without any way to disable it (in which case there is no API change)? Or do we consider slack-web is the wrong layer in the stack to deal with that, and we change nothing compared to the current situation?