Handle "429 Too Many Requests"

[dcastro]

Clarification and motivation

Sometimes, we may hit Slack's rate limits and Slack's Web API will start responding with 429 Too Many Requests. When this happens, the response should have a Retry-After header indicating how many seconds we should wait before retrying the request.

You can find the current implementation of the Web API client in TzBot.Slack.WebAPI.Impl.

We should give up after 3 attempts (we can make this number configurable later).

Acceptance criteria

• We gracefully handle Slack's rate limits.
• The app doesn't crash when we get a 429.
• We wait the given number of seconds before retrying the request.

[Martoon-00]

Should we let the user know that the time will be translated, but a bit later?

Also, probably we should think about how much delay can we afford. In case of intense discussion involving many messages that include time, we should avoid the following situation:

A: 15:00
B: 16:00
C: 15:30
Slackbot: <translated 15:00>
Slackbot: <translated 16:00>
D: 16:30
Slackbot: <translated 15:30>
...

[dcastro]

Should we let the user know that the time will be translated, but a bit later?

But in order to let the user know about this, we'd have to send them an ephemeral message. And if the rate-limiting is preventing us from telling them the translated time, surely it'll also prevent us from informing them about the delay :/

Also, probably we should think about how much delay can we afford. In case of intense discussion involving many messages that include time, we should avoid the following situation:

Yup, I think, after we have a fully working MVP, then we can stress test it and see if it's a problem in practice (and if it is, what we can/should do about it).

[Martoon-00]

But in order to let the user know about this, we'd have to send them an ephemeral message.

Oh right :smile:

Yup, I think, after we have a fully working MVP, then we can stress test it and see if it's a problem in practice

Sounds good :+1: