Improve rate-limit handling

Reproducible in:

The Slack SDK version

slack-sdk==3.34.0
slackeventsapi==3.0.3

Python runtime version

Python 3.8.5

OS info

90~20.04.1-Ubuntu SMP Tue Apr 22 09:59:53 UTC 2025

Recently my Slack app continuously failed for a few hours in the following manner (US Eastern time).

2025-05-27 11:07:23,389 ERROR    slack_sdk.web.base_client Failed to decode Slack API response: Received a response in a non-JSON format: 
2025-05-27 11:07:23,389 ERROR    slack_sdk.socket_mode.builtin.client Failed to run a request listener: The request to the Slack API failed. (url: https://slack.com/api/team.info)
The server responded with: {'ok': False, 'error': 'Received a response in a non-JSON format: '}

The body of the response from the Slack API was empty.

Later that day, starting at 2025-05-27 14:16:56 and ending at 14:18:05 I ran the following commands seven times.

curl -vH "Authorization: Bearer <token-redacted>" https://slack.com/api/team.info; echo

The seventh run produced the following output.

*   Trying 54.92.199.186:443...
* TCP_NODELAY set
* Connected to slack.com (54.92.199.186) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=slack.com
*  start date: Mar 28 10:53:37 2025 GMT
*  expire date: Jun 26 10:53:36 2025 GMT
*  subjectAltName: host "slack.com" matched cert's "slack.com"
*  issuer: C=US; O=Let's Encrypt; CN=R10
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5632a8e5e0d0)
> GET /api/team.info HTTP/2
> Host: slack.com
> user-agent: curl/7.68.0
> accept: */*
> authorization: Bearer <token-redacted>
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 429
< x-edge-backend: envoy-www
< via: envoy-edge-iad-swgvnnyy
< x-envoy-ratelimited: true
< x-slack-edge-shared-secret-outcome: no-match
< date: Tue, 27 May 2025 18:18:05 GMT
< server: envoy
<
* Connection #0 to host slack.com left intact

Note in particular:

• the empty response body
• the x-envoy-ratelimited: true header

I described the problem to Slack support and in their prompt and helpful response they indicated the x-envoy-ratelimited: true header suggests this was handled via Slack's CDN or API gateway, which in rare cases may result in a 429 with an empty body instead of a JSON-formatted error. Requests are being throttled before reaching the Slack application layer.

The Python Slack SDK clearly doesn't handle this scenario well, e.g., the SDK's code is unable to honor any rate-limiting error handlers that are configured. Can the handling be improved?

Thanks.

Start at the slack_sdk.web.base_client response handling and the slack_sdk.socket_mode.builtin.client request path shown in the logs. Trace how an empty non-JSON 429 response is represented and how configured rate-limit handlers are reached. Done means this gateway response is handled without losing rate-limit behavior; add or run coverage for the empty-body case if the relevant tests are identified.