-
Notifications
You must be signed in to change notification settings - Fork 850
Description
Description
On very large Slack teams, the rtm.start payload can be too large to deliver before a timeout (server timeouts would return response 500, but also the websocket URL itself is short-lived so the timeout could be from the time it takes for the client to read the response).
The Slack platform has a new method called rtm.connect which is much smaller and faster to load. It also would provide the websocket URL.
I think this can be implemented as a swap of one for the other because the rtm.start data is not being returned to the user anyway (see #181), so that means there's no breaking API change by not having all the same data. The point about that data being valuable is valid though, so I propose that the default would be to use rtm.connect (better for most people anyway) and there is an option for using rtm.start, and in both cases the data is returned.
What type of issue is this? (place an x in one of the [ ])
- bug
- enhancement (feature request)
- question
- documentation related
- testing related
- discussion
Requirements (place an x in each of the [ ])
- I've read and understood the Contributing guidelines and have done my best effort to follow them.
- I've read and agree to the Code of Conduct.
- I've searched for any related issues and avoided creating a duplicate issue.