Hubot-slack: Hubot cannot connect to Slack and return me "Socket URL has expired"

[tlytg456]

Description

Hello,
From yesterday afternoon, I found my Hubot cannot connect to slack, and the error message is:

[Wed Oct 24 2018 10:35:42 GMT+0800 (CST)] INFO Logged in as @xxx in xxxxxx
warn: No pong in 1540348543287ms, treating error as keep-alive
[Wed Oct 24 2018 10:35:43 GMT+0800 (CST)] ERROR Slack RTM error: {"type":"error","error":{"msg":"Socket URL has expired","code":1,"source":"gs-sin-1s8n"}}
[Wed Oct 24 2018 10:35:43 GMT+0800 (CST)] ERROR undefined
warn: Reconnecting, on attempt 1

The hubot keep trying to connect slack but always failed. Do anyone have any ideas about that?
Thanks in advanced.

What type of issue is this? (place an x in one of the [ ])

• [ ] bug
• [ ] enhancement (feature request)
• [ ] question
• [ ] documentation related
• [ ] testing related
• [x] 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.
• [x] I've searched for any related issues and avoided creating a duplicate issue.

---

Reproducible in:

hubot-slack version: 4.5.5

node version: 8.9.1

OS version(s): Ubuntu 16.04 LTS

[ben-nat-wallis]

@tlytg456 we've been having this issue with our slack bot as well. It's not at the point where the bot is pretty much useless because it only stays connected for a few hours before disconnecting. We're currently using version 2.19.0, running via a docker container. We get the same kind of logs:

warn: No pong in 30020ms, treating file_public as keep-alive,
warn: Reconnecting, on attempt 1

Is there any solution in the works for this? I would like my team to start using our chat bot again, but as it is right now, it's just not usable.

[tlytg456]

@ben-nat-wallis yes, I have feedback to Slack official, and this is his response:

It looks like your workspace has a fairly high number of users/channels, so it's possible that you'll need to use the rtm.connect method to initiate your connection rather than rtm.start.
This can be done by using the following initialization options: { dataStore: false, useRtmConnect: true }
See: https://github.com/slackapi/hubot-slack/blob/master/src/client.coffee#L26

I added a params into the bot start:

ENV HUBOT_SLACK_RTM_CLIENT_OPTS='{  "dataStore": false, "useRtmConnect": true }'

Maybe you can try it in your env, good luck

[ben-nat-wallis]

@tlytg456

I added that env variable, but I'm still getting the same output. I noticed that in the startup the options are being passed, but it still seems to be calling rtm.start

[Tue Oct 30 2018 09:49:05 GMT+0000 (Coordinated Universal Time)] DEBUG Loading adapter slack,
[Tue Oct 30 2018 09:49:06 GMT+0000 (Coordinated Universal Time)] INFO hubot-slack adapter v4.5.4,
[Tue Oct 30 2018 09:49:06 GMT+0000 (Coordinated Universal Time)] DEBUG RtmClient initialized with options: {"dataStore":false,"useRtmConnect":true,"maxRequestConcurrency":1,"retryConfig":null},
[Tue Oct 30 2018 09:49:06 GMT+0000 (Coordinated Universal Time)] DEBUG RtmClient#start() with options: {}

[sankalp-khare]

FYI I found this to be happening to me (also a large org, and same response from slack support as posted by @tlytg456) due to the slowness of my internet connection at home.

The same setup (no changes at all) works great when used from a Virtual Machine in our Company Network where the internet link is significantly speedier.

The idea that network bandwidth could be a factor is thanks to https://github.com/slack-ruby/slack-ruby-client/issues/134