Implement Rate Limit Handling for Slack's New API Limits

[PeterDaveHello]

With the new rate limit policies from Slack's May 2025 update (https://api.slack.com/changelog/2025-05-terms-rate-limit-update-and-faq), deployments of this application are susceptible to hitting API rate limits, resulting in HTTP 429 (Too Many Requests) errors.

Since Slack does not provide a way to adjust rate limit tiers, we may need to implement internal controls to ensure the app remains reliable and stable.

Problem

• The app's usage pattern can easily trigger Slack's API rate limits.
• This leads to service disruptions and a poor user experience.

Proposed Solutions

1. Request Throttling:

   • Implement a queue system to manage the rate of outgoing API calls.
   • Introduce a configurable delay between requests.

2. Retry Mechanism:

   • Implement a progressive backoff strategy for retries upon receiving a 429 error (e.g., waiting 1s, then 2s, 3s, 5s, etc.) to effectively manage request frequency.

3. Basic Monitoring:

   • Add logging to track API usage and the frequency of rate limit events, helping administrators understand their instance's load.

Further discussion and suggestions on handling rate limiting are welcome.

[seratch]

Hi @PeterDaveHello, thanks for bringing up this topic. Slack's rate limits are applied per workspace + app + endpoint. This means that, with the new non-Slack Marketplace app restrictions, only one person in a workspace can use this app's conversation feature per minute. Given that, I have to say that none of the proposed solutions would work well.

The only possible solutions I can think of are: 1) saving each message event in your database and using that data instead of calling the conversations.history/replies APIs, or 2) getting approval to list your app on the Slack Marketplace. I don't want to implement option 1 because it could make this app's development and operations more complex. For option 2, if you're okay with making your app based on this repo public, it might be a good path for you.

Either way, there isn’t an easy solution here. According to the announcement, a new search endpoint may be introduced. If that endpoint is useful for this app, I might migrate to it. Otherwise, the app will have to disable the conversation feature w/ context in channels by default. This means this app will be available mainly on the Home tab.

[PeterDaveHello]

Thank you for the explanation and context, @seratch. I understand the workspace + app + endpoint rate limit is a hard restriction and cannot be bypassed.

From a conceptual perspective, one possible mitigation is to implement throttling by introducing a short, configurable delay before each API call. Additionally, handling the Retry-After header on 429 responses could help the app recover more gracefully when the limit is reached.

These approaches may not solve the issue for high-traffic workspaces, but they could still improve reliability for low-traffic scenarios. Open to your thoughts on whether these adjustments make sense in this context.

[seratch]

Thanks for your reply. Your suggestion is indeed better than nothing. However, in real use cases, even with the rate limiter, you can only receive one reply per minute across the entire workspace. This means that even if you are the only active user, you still won't be able to receive multiple replies within a minute. To me, this makes the feature almost useless....

So, if we want to fundamentally resolve this issue, we need to add an optional module to save message event data in a database table and avoid calling the conversations.history/replies APIs to check the conversational context.

An ideal solution would be for Slack to update the message event payload to include the last few messages in a thread or channel as well. That way, we wouldn't need to call the APIs to provide conversation context to the LLM.