RTMClient may spew rtm.connect calls causing Slack Servers to rate limit

[pbrackin]

We had an issue where new message events were not arriving for a short time. Our logs didn't show any issue, so I opened a ticket with the Slack backend folks. They apparently did a post-mortem which showed too many rtm.connect calls coming in rapid succession. Eventually they said there were 22 calls in total during this short time. They further advised that our app was rate limited due to this and that we should open a ticket up here since we are using the RTMClient.

As we don't make the rtm.connect calls directly, I am wondering if this is a known issue with the client code, or if there is some additional debugging we could do?

Notes:

• This occurred immediately after the service was started. You may recall that we periodically restart the service due to the Django ORM issue.
• This may be very rare. We have only seen this one time that we know of in over a year.

Reproducible in:

The Slack SDK version

slackclient==2.6.2
slackeventsapi==2.1.0

Python runtime version

Python 3.6.9

OS info

118-Ubuntu SMP Fri Sep 4 20:02:41 UTC 2020

Steps to reproduce: Connect with RTMClient

(Share the commands to run, source code, and project settings (e.g., setup.py))

    self.rtm_client = RTMClient(
        token=self.slack_token,
        connect_method='rtm.connect',
        run_async=False
    )

      rtm_thread = Thread(target=self.rtm_client.start)
      rtm_thread.daemon = True
      rtm_thread.start()

Expected result:

1. client connects with single rtm.connect call or with backoff timer between calls
2. all messages received

Actual result:

1. multiple rtm.connect calls in rapid succession
2. some messages are missing

Requirements

For general questions/issues about Slack API platform or its server-side, could you submit questions at https://my.slack.com/help/requests/new instead. 🙇

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

[seratch]

Hi @pbrackin, thanks for asking this question!

With given information, it seems that this line is repeatedly called without having any exception. If the server-side returns any of error code in response body, non-200 http status code, or request timeout (it didn't respond), an exception should be thrown and the RTMClient should exponentially wait until the next call. I'm not sure about the root cause of your issue yet.

I'm sorry to say this but we are not actively updating the legacy RTM client. I would suggest switching to slack_sdk.rtm_v2.RTMClient: https://slack.dev/python-slack-sdk/real_time_messaging.html#real-time-messaging-rtm

The v2 client is a completely new implementation. It does not depend on AIOHTTP in an irregular way. Also, the v2 client reuses the Socket Mode client's WebSocket connection management logic, which has been stably working for many users for more than a half year. Plus, you don't need to restart your application periodically with the v2 client.

I hope this was helpful to you.

[pbrackin]

OK yeah I had seen that about the v2 RTMClient and also that the Socket Mode flavor had come out. I think we will explore one of those 2 options soon. I thought that at one point they were doing away with the RTM apps; I guess that is why Socket Mode has come out (to address the corporate firewall nightmares without RTM apps). What are the advantages / disadvantages of switching to a Socket Mode app vs keeping the RTM app? I'd probably prefer to avoid deploying new apps or converting the existing apps we have, if possible.

[seratch]

@pbrackin Thanks for your reply! The general advantages of Socket Mode over the RTM would be:

• Your apps can handle not only Events API patterns but also user interactions (e.g., modal data submission, slash command / shortcut invocation, workflow executions)
• Continued feature addition (new events will be added only to Events API, new interactivity events may come in the future)

I hope either migrating to the RTM client v2 or the Socket Mode works better for you.

[pbrackin]

Thanks @seratch for the info. I will close this one out....