Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adapt to Slack API changes #235

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

binaryseed
Copy link
Contributor

This PR makes a few changes to adapt to Slack API changes...

  • It extends the handle_connect callback to enable initializing both the slack and process_state
  • Connect via the rtm.connect instead of rtm.start API
  • The HTTP client is set to :atom keys since that's what everything inside this library already expects

Some docs changes are likely in order, and can be added...

fixes #233

@@ -42,6 +42,6 @@ defmodule Slack.Rtm do

defp slack_url(token) do
Application.get_env(:slack, :url, "https://slack.com") <>
"/api/rtm.start?token=#{token}&batch_presence_aware=true&presence_sub=true"
"/api/rtm.connect?token=#{token}&batch_presence_aware=true&presence_sub=true"
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we change start to connect here, could that cause issues for people who are still relying on the old start behavior?

If that's the case, I wonder if it makes sense to make a new connect method that uses rtm.connect while keeping the start method that keeps using rtm.start?

Copy link
Contributor Author

@binaryseed binaryseed Sep 2, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What led to this is that I noticed that my bot was fully broken, and rtm.start always returned a 429 rate limit error, even with a single request. I interpreted that as Slack turning off the API.

Perhaps that behavior differs for older Bots though?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes this was fundamentally the issue I ran into with #177 (which lead to #184 and #190)

Copy link
Collaborator

@acconrad acconrad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to address @BlakeWilliams 's concerns because we saw this before with a previous iteration I did when trying to switch over to rtm.connect

@binaryseed
Copy link
Contributor Author

Ok, so maybe make this configurable? Or perhaps this is a major version bump?

@binaryseed
Copy link
Contributor Author

Another possibility is to make this "forward compatible" by using rtm.connect doing all the init lookups that rtm.start used to include...

@acconrad
Copy link
Collaborator

@BlakeWilliams I had proposed a major version bump back last time - is this the point we make the cutoff?

@BlakeWilliams
Copy link
Owner

Since we're below 1.0, we can technically make breaking changes at any time. Although I'd prefer we don't make breaking changes when we can avoid them.

I think the best way forward is supporting both approaches since I think some bots will currently rely on the old behavior still being present. But we could recommend the new approach over the old one in the README and documentation. If we want to move towards a 1.0 release, I think an issue tracking some of the required work would be great 👍

@parkerjm
Copy link

parkerjm commented Feb 21, 2022

Hey guys, any movement on this? The library currently doesn't work for any bots/apps created after November 2021, as the rtm.start endpoint returns an error for any new bots/apps. I had to create an altered version of this lib in order to get my new bot to work. I was about to submit a PR when I found this one.

Maybe the lib could attempt to connect to rtm.start, detect the deprecation error, and connect to rtm.connect instead.

@parkerjm
Copy link

parkerjm commented Feb 21, 2022

FYI, slack has stated:

For existing apps, rtm.start will start behaving exactly like rtm.connect on September 20, 2022.

https://api.slack.com/changelog/2021-10-rtm-start-to-stop

@peixian
Copy link

peixian commented Sep 26, 2022

Is there a blocker for this PR to get upstreamed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Slack RTM breaking changes
5 participants