How to Monitor and Handle auth.test Throttling in Slack BoltJS SDK (v3)

[sanjay1909]

Question

We are encountering challenges in monitoring and handling rate limit errors, specifically for the auth.test API call, when using the Slack BoltJS SDK (v3) with the AWS Lambda Receiver. The SDK’s internal handling of rate limits abstracts visibility, making it difficult to track throttling events in real-time or implement centralized monitoring.
We are looking for guidance or best practices to improve our ability to handle and monitor these events proactively.

Context

1. Our system is built using the Slack BoltJS SDK (v3) with AWS Lambda Receiver.
2. auth.test is called internally by the SDK, and rate-limiting errors are managed without exposing sufficient details.
3. We need better insights into:
   3.1 When throttling occurs.
   3.2 Retry intervals (Retry-After)
   3.3 A way to log or intercept these errors for centralized monitoring.

Specific Questions

1. How can we track throttling events for auth.test in real-time?
   Is there a way to configure the SDK or use a custom logger to capture detailed information about rate-limit errors, including:
   1.1 API call details (e.g., auth.test).
   1.2 Retry intervals (Retry-After header).
   1.3.Timestamps or contextual metadata?
2. Can we intercept and handle rate-limit errors manually?
3. What are Slack’s recommendations for centralized monitoring of throttling issues?
4. Are there built-in hooks or best practices for integrating Slack rate-limit events with external monitoring tools (e.g., CloudWatch, Datadog)?
5. Are there SDK configurations or middleware patterns to address these challenges?
   Could we implement a middleware to capture and log rate-limit events without disrupting the SDK’s core functionality?

Request

We would greatly appreciate Slack’s guidance on the following:

1. Steps to monitor throttling errors effectively within the BoltJS SDK.
2. Configuration options or patterns to handle auth.test rate-limiting issues.
3. Any documentation or examples on handling Slack rate limits in high-traffic systems.

Environment

1. Slack BoltJS SDK Version: v3.x
2. Environment: AWS Lambda Node.js runtime
3. Receiver: AWS Lambda Receiver

Thank you in advance for your help! Please let us know if further clarification or additional details are needed.

[seratch]

Hi @sanjay1909, thanks for asking the question!

When your WebClient receives a rate-limited error and it attempts retries, the web-api package prints info-level logging, indicating that an error occurred and how long it will wait: https://github.com/slackapi/node-slack-sdk/blob/%40slack/web-api%407.8.0/packages/web-api/src/WebClient.ts#L670 Checking this output in your logs is the quickest way to investigate for now, while we're happy to add more mecanism to enable developers to have hooks for the timing in future releases.

In considering the specific auth.test API scenario, I believe rate limit errors usually don't occur because the endpoint has a "special" rate limiting tier, which permits hundreds of requests per minute (we don't disclose further specifics than the document but it should handle more during a temporary spike). That said, if you're running your app in extremely large enterprise workspaces where many event requests are sent simultaneously, such a situation could indeed arise.

When considering possible workarounds, here are two suggestions I can offer:

• If your app operates for a single workspace/organization, implementing your own "authorize" function with a static auth.test result should resolve the issue; Refer to https://tools.slack.dev/bolt-js/concepts/authorization and https://github.com/slackapi/bolt-js/blob/%40slack/bolt%404.1.1/src/App.ts#L1374-L1393 for details
• IIf your app can be installed into multiple workspaces, implementing a cache layer for the "authorize" function is an option. It’s best to use ElastiCache or a similar option, rather than relying on in-memory storage within the Lambda runtime.

I hope this was helpful to you.

[github-actions]

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.

[sanjay1909]

Hi Sorry for the late response ,

Thank you for the detailed response.

currently we implemented using Token Ration
Token Rotation

Our App in installed in single work space .

What do you recommend is to implement using authorization ?

[sanjay1909]

In Terms of monitoring which API call is rate limited
https://github.com/slackapi/node-slack-sdk/blob/%40slack/web-api%407.8.0/packages/web-api/src/WebClient.ts#L670
This log say its rate limited, how do we know which one.

Its the API we invoked or the auth.test API invoked by BoltJS SDK ?