Slack RTM caching Run_async

[ashvinnihalani]

Description

Describe your issue here.

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.

---

Bug Report

Filling out the following details about bugs will help us solve your issue sooner.

Reproducible in:

slackclient version: 1.3.1

python version: 3.6.8

OS version(s): Windows 10

Steps to reproduce:

1. Start RTM client with run_async set to false
2. Cancel and change to true and rerun
3. Cancel and remove arg and rerun
4. Try a web_api get method I was user_info

Expected result:

What you expected to happen
Wait until client returns with a response

Actual result:

What actually happened
Returns an async task item

Attachments:

Logs, screenshots, screencast, sample project, funny gif, etc.
assert result["ok"] == True TypeError: '_asyncio.Task' object is not subscriptable

[DaAwesomeP]

I am experiencing this with the latest master with the WebClient. I am not specifying run_async, so it should be False, but I am getting returned async tasks.

[clavin]

Thank you for the report! I've searched around and I believe I've found the cause of this bug: 🐛

It seems that the RTMClient is creating its inner WebClient with run_async always set to True; that is, the RTMClient's WebClient (the one that gets passed to event callbacks) doesn't inherit the RTMClient's run_async option. This means the web_client parameter passed to event callbacks will always be async (as the code currently is).

Unfortunately, a fix is more complicated than simply replacing that line with run_async=self.run_async because that WebClient instance is used (in an async manner) by the RTMClient implementation. 😞

It makes sense to me that the WebClient instance passed to event callbacks should inherit the RTMClient's run_async option, so I'm marking this one as a bug.

---

A workaround for now might be to just create your own WebClient and use that instead of the one supplied by the RTMClient, though I don't know how this affects the RTMClient implementation.

[seratch]

#662 fixes the issue where run_async arg in the constructor is not reflected.

[seratch]

Let me close this issue now as #662 is resolving it.