Python-slack-sdk: rtm_connect() is now always returning False

[Zechtitus]

• [X] I've read and understood the Contributing guidelines and have done my best effort to follow them.
• [X] I've read and agree to the Code of Conduct.
• [X] I've searched for any related issues and avoided creating a duplicate issue.

Description

rtm_connect() is always returning False

Reproducible in:

following guide here will show the issue:
http://slackapi.github.io/python-slackclient/real_time_messaging.html#connecting-to-the-real-time-messaging-api

For my project I was using docker with python 2.75 + ubuntu 16.04

Steps to reproduce:

1. Follow guide the line sc.rtm_connect() will always return False
2. This was working up to a week ago. I rebuilt containers with slack project and they all started seeing this. Nothing else was change in container except moving them to a different instance. Retried on the old instance to verify it wasn't network and problem was also seen then.

Expected result:

sc.rtm_connect() should return true

Actual result:

Always returns false.

Extra Info:

I got feedback from slack about the issue and they were suggesting that I try out the newer rtm.connect method
https://api.slack.com/changelog/2017-04-start-using-rtm-connect-and-stop-using-rtm-start

I believe this is in reference to this line: https://github.com/slackapi/python-slackclient/blob/master/slackclient/_server.py#L70

[arjun-io]

I'm seeing the same error. I stepped through this with pdb and it seems to error out here: https://github.com/slackapi/python-slackclient/blob/master/slackclient/_server.py#L107 with this error message TypeError('cafile, capath and cadata cannot be all omitted',) which looks like some sort of certificate error.

[pseudocodes]

Add sslopt={"cert_reqs": ssl.CERT_NONE} in https://github.com/slackapi/python-slackclient/blob/master/slackclient/_server.py#L103

[gbigwood]

Would it be possible to have the connect throw an exception rather than just returning False? It would greatly help me understand what has gone wrong.

on this line: https://github.com/slackapi/python-slackclient/blob/f8ebd4a20e513792748d3689eb375528a389f84f/slackclient/_server.py#L109
by using ipdb I managed to find the following error

File "/home/app/lib/python3.5/site-packages/websocket/_http.py", line 138, in _wrap_sni_socket
    context.load_verify_locations(cafile=sslopt.get('ca_certs', None), capath=sslopt.get('ca_cert_path', None))
TypeError: cafile, capath and cadata cannot be all omitted

Is it possible to use raise from? I'm not sure how backwards compatible that would be but it is nice to be able to see the causes of the exceptions.

[Zechtitus]

Update:
I went and installed the requirements.txt that was in the repo:
https://github.com/slackapi/python-slackclient/blob/master/requirements.txt

specifically this 'websocket-client==0.35.0'

reran and it's back up to working! Thanks to Guanliang Chen for pointing me in that direction!

possible the docker image I was using had an update removing one of those packages? unsure why it worked before.

[gbigwood]

Confirmed that websocket-client==0.35.0 in requirements is a fix. (We've actually gone with 0.40.0 which also seems to work)

My problem before: (pipdeptree output):
```
slackclient==1.0.5

• requests [required: Any, installed: 2.13.0]
• six [required: Any, installed: 1.10.0]
• websocket-client [required: Any, installed: 0.43.0]```

[ipari]

I had a same problem and websocket-client==0.40.0 solved this.

[aoberoi]

im working on some packaging cleanup in #188. im adding version range specifiers to the dependencies, and currently i have websocket-client >=0.16, <1.0a0. but it seems like from this issue, i should change that to websocket-client >=0.35, <1.0a0.

i haven't tried reproducing, but do we agree that this would fix the issue?

[Zechtitus]

@aoberoi - possibly... For me the only thing I did between working and not working was to docker build using ubuntu 16.04 image. I hadn't modified slackclient (was at 1.0.5) - I am guessing something new was pushed to the docker image that caused this?

[aoberoi]

@Zechtitus i'm guessing your Dockerfile does a fresh pip install -r requirements.txt in there somewhere, so your new build probably got a later version of websocket-client. is there any way you could access the non-working docker image and figure out what version of websocket-client was on it?

[Zechtitus]

@aoberoi - found one app I hadn't upgraded yet. This is weird as if I'm reading this correct it was saying 0.43.0 of websocket-client was installed... but this app was still getting the False back with the rtm_connect() call

from pipdeptree

slackclient==1.0.4

• requests [required: Any, installed: 2.18.1]
  
  
  
  • certifi [required: >=2017.4.17, installed: 2017.4.17]
  
  
  • chardet [required: >=3.0.2,<3.1.0, installed: 3.0.4]
  
  
  • idna [required: >=2.5,<2.6, installed: 2.5]
  
  
  • urllib3 [required: <1.22,>=1.21.1, installed: 1.21.1]
  
  
• six [required: Any, installed: 1.10.0]
• websocket-client [required: Any, installed: 0.43.0]
  
  
  
  • six [required: Any, installed: 1.10.0]
  
  

[Roach]

Would it be possible to have the connect throw an exception rather than just returning False? It would greatly help me understand what has gone wrong.

@gbigwood I agree. Much of the error handling in this module could use some refactoring. Many errors are either not propagated up the chain properly or completely hidden from the developer.

We've been working out roadmaps for our SDK projects and improved error handling is a common theme among them.

[aoberoi]

okay, im going to try a few versions locally and see if i can help narrow down the offending version (if that's truly the only thing wrong)

[aoberoi]

alright folks, i think we've narrowed it down. it seems to be caused by https://github.com/websocket-client/websocket-client/commit/287db85a429a3c413411415663fde8c5a339de42.

@Roach and i submitted a patch (websocket-client/websocket-client#328) and hopefully that gets merged and released.

so in conclusion, the v0.43.0 release of websocket-client is broken. its no coincidence that this issue started getting reported here a day ago (when that version was released). lets be patient for the next release or revert to a previous one.

[aoberoi]

⬆️ that was a mistake because of auto-closing from the commit.

[aoberoi]

im mostly certain that v0.44.0 on pip includes our patch. i'll go ahead and close this issue.

[edwinksl]

@aoberoi Hmm, I am still getting False from rtm_connect(). Using slackclient (1.0.6) and websocket-client (0.44.0).

[CFlower]

I was experiencing this error, updating websocket-client to v0.44.0 via pip indeed fixed it for me.

[aoberoi]

@edwinksl are you able to either of the following?

1. use pdb to set a breakpoint in server.py line 103 and try stepping over until you see an error, or;
2. enable tracing by placing the following lines in your program but before calling rtm_connect()
python import websocket websocket.enableTrace(True)

if you can do (1), then please see if the exception matches the one we're talking about and let me know.

if you can do (2), can you post the trace output you see on the console (please redact any tokens or confidential information)?

[edwinksl]

@aoberoi My bad, there was a missing scope, which I have now fixed, so it wasn't a problem with rtm_connect(). After adding the missing scope, rtm_connect() works as expected.

[mberaha]

I have the same issue using slackclient (1.0.6) and websocket-client (0.44.0).

after calling
client = slackclient.SlackClient(botToken)
The following returns True
client.api_call("users.list").get('ok')

While client.rtm_connect() is False

I also tried websocket.enableTrace(True) but no output gets printed on terminal

[edwinksl]

@mariob6 As noted above, you need to upgrade websocket-client to 0.44.0.

[mberaha]

@edwinksl my bad I updated it while trying but still no luck (I changed my comment)

[aoberoi]

@mariob6 i'm not sure what to say about no output with enableTrace(), but have you tried debugging with pdb? is there any new information about the issue since you last commented?

[mberaha]

thanks @aoberoi I was using bash on Ubuntu on Windows, I switched to a full Ubuntu system and it worked smoothly

[aoberoi]

i'm glad you got it working!

its a shame the bash on Windows support is a little more nuanced. if you have any more details about that problem, we could start documenting what we know about it in a new github issue.