slack: Unable to complete connection

First of all, I suspect this might be an issue with the configuration of the bot on slack website, because the same code works on a different slack account/workspace, but I cannot compare the configuration.

The issue is as follow: when I start the bot it looks like authentication is correct, but then the bot receive an empty event and starts flooding slack with PING until the connection is closed.

slack-bot: 2018/01/07 12:19:57 misc.go:79: parseResponseBody: {"ok":true,"self":{"id":"U8NG78932","name":"napp","prefs ...
slack-bot: 2018/01/07 12:19:57 slack.go:92: Using URL: wss://mpmulti-xxxx.lb.slack-msgs.com/websocket/...
Connection counter: 1
slack-bot: 2018/01/07 12:19:58 slack.go:92: Incoming Event: {}
slack-bot: 2018/01/07 12:19:58 slack.go:92: Sending PING  1
slack-bot: 2018/01/07 12:19:58 slack.go:92: Sending PING  2
slack-bot: 2018/01/07 12:19:58 slack.go:92: Sending PING  3
...
slack-bot: 2018/01/07 12:19:58 slack.go:92: Sending PING  1587slack-bot: 2018/01/07 12:19:59 slack.go:86: RTM Error sending 'PING 1749': write tcp 172.22.1.42:64433->35.187.106.147:443: write: broken pipe
slack-bot: 2018/01/07 12:19:59 slack.go:92: killing connection
slack-bot: 2018/01/07 12:19:59 misc.go:79: parseResponseBody: {"ok":true}

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 1
  • Comments: 21 (2 by maintainers)

Most upvoted comments

Hey folks, Slack Platform engineer here 👋

We’ve noticed many bots using this library have had issues connecting to RTM over the last couple days. I want to bring some clarity around what happened.

We’re rolling out a change (to a percentage of teams at a time and it will reach 100% relatively soon) that slightly modifies the websocket URL you receive after calling rtm.start or rtm.connect web API methods. The difference is there is a query string included, where there was none before.

That seems to have tripped up the code in this package. But I’m really happy to see the smart folks that work on this package and the community of its users come together to find a fix! Since we’ve identified the cause we’re trying to do our part and proactively reach out to the larger bots on our platform that seemingly use this package to give them a heads-up about the change and point them to updating this package to minimize impact on their operations.

Please feel free to reach me if you have any further questions about this change. I’m @aoberoi on twitter and the Bot Developer Hangout (http://dev4slack.xoxco.com/). Once we’re out of the woods on this issue, I’d love to chat with the maintainers to see if there’s anything we can do to work more smoothly with you in the future.

I was able to get slack bot back online by updating to latest commit on master. https://github.com/nlopes/slack/commit/107290b5bbaf3e634833346bb4ff389b1c782bc7 Note that the last release v0.1.0 will not work.

@aoberoi Already have a ticket open with Slack…

I tried out the changes in the PR #238 and the bot started working…

Oh, one more thing. After applying the latest update, you may need to remain disconnected for several minutes before trying to connect again. That’s because the rtm.start and rtm.connect methods are rare-limited, and since your bot was likely hammering those methods previously to try and reconnect, our platform would like you to slow down.

There’s definitely an opportunity for an enhancement to the code to deal with the 429 response code and retry headers in a more intelligent way. We should probably spin up another Issue for this feature.