asyncio RuntimeError stacktrace in SlackResponse, when getting paginated responses

[ryan-lane]

Description

I'm trying to get paginated responses in users_list, by providing cursor and limit, but I'm getting a RuntimeError when doing so, because there's no existing asyncio loop in the thread:

https://github.com/slackapi/python-slackclient/blob/e06b4d7b415aac439ec9d5456ef756aaed4083e9/slack/web/slack_response.py#L135

Applying the same pattern that base client uses for getting an event loop fixes the issue:

https://github.com/slackapi/python-slackclient/blob/e06b4d7b415aac439ec9d5456ef756aaed4083e9/slack/web/base_client.py#L49-L56

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: 2.5.0

python version: 3.x

OS version(s): Ubuntu bionic

Steps to reproduce:

1. Try to get a paginated response without generating an event loop (my code doesn't use asyncio)
2. Try to get a paginated response
3. Get a stacktrace

Expected result:

I expect to get paginated results.

Actual result:

I get a RuntimeError

[ryan-lane]

Relevant part of the stacktrace:

  File "/srv/service_venv_python3.6/lib/python3.6/site-packages/slack/web/client.py", line 1615, in users_list
    return self.api_call("users.list", http_verb="GET", params=kwargs)
  File "/srv/service_venv_python3.6/lib/python3.6/site-packages/slack/web/base_client.py", line 171, in api_call
    return self._event_loop.run_until_complete(future)
  File "/usr/lib/python3.6/asyncio/base_events.py", line 454, in run_until_complete
    self.run_forever()
  File "/usr/lib/python3.6/asyncio/base_events.py", line 408, in run_forever
    raise RuntimeError('This event loop is already running')
RuntimeError: This event loop is already running

[aoberoi]

Hi @ryan-lane, thanks for taking the time to research and write this up.

I've tried reproducing the issue as you describe but the code seems to work as expected for me. Here is what I have:

import os
from slack import WebClient

token = os.environ.get("SLACK_BOT_TOKEN")
client = WebClient(token=token)

# Making a paginated Web API request
# Using a really low limit to artificially create the need for more than one request
for page in client.conversations_list(limit=5):
    print(page)

Note that I don't have asyncio or any event loops in my program. In a workspace with about 100 conversations, it paginated through the entire set as expected.

Looking a little closer at your error, it seems like the problem isn't about asyncio.get_event_loop() failing because there's no event loop running (in fact, the documentation says calling this function would just create one in that condition). Instead, it seems like your program has an event loop running: RuntimeError: This event loop is already running. Can you check this out?

This is still a bug we need to solve, but I'm trying to collect a little more information so we can come up with a good solution. I'm looking at your PR (#632) and I'm not quite sure if and how it fixes the problem. The call to get_event_loop() is not the one that throws the RuntimeError in your example - it's run_until_complete(future) that throws. As far as I can tell, with that patch applied the get_event_loop() method would just return your existing event loop and the except clause would never run. Therefore we'd be back in the same place.

[seratch]

Let me close this issue now as #662 resolved it.

[seratch]

👋 slackclient 2.6.0rc1 is out. The pre-release version contains fixes for your issue described here.
https://pypi.org/project/slackclient/2.6.0rc1/

One week later from now, we'll be releasing version 2.6.0 to PyPI.

If you have a chance, could you try the release candidate version out and let us know your feedback? Thank you very much for being patient with this issue.