API Cursor Pagination Performance : conversations.list

[AlexAtkinson]

The behavior characteristics and performance of iterating the cursor through conversations.list is truly awful when it is being used to resolve a channel name to a channel id.

For example, if I create a new channel in an org that's been around for a while, with limit=200, that channel is returned on page 135, and the pagination sequence takes 7m38.503s to resolve with 20 calls per minute (tier 2 rate limit).
When inspecting the responses, it can be seen that the channels returned never reach the limit count, and progressively diminish, eventually returning no results across cursors, sometimes 2, sometimes 10, etc., until finally resolving.

Please, either create a new class of methods that support resolving user or channel names directly to their IDs, or optimize the data that feeds the pagination to enable the methods to return valuable data earlier in the pagination sequence.

This is related to the last bullet under Just The Facts:

It's possible to receive fewer results than your specified limit, even when there are additional results to retrieve.

Note
This started when looking at chat.update and seeing that it required a channel id rather than a channel name (I tested it and it's not just a docs issue...). Rather than fixing the above situation, if you can align the chat.postMessage and chat.update methods to both accept a channel name, then that would satisfy my original problem. Though, the above deficiency will still exist. I've made a separate issue for this here.

Category (place an x in each of the [ ])

• [X ] slack_sdk.web.WebClient (sync/async) (Web API client)
• slack_sdk.webhook.WebhookClient (sync/async) (Incoming Webhook, response_url sender)
• slack_sdk.models (UI component builders)
• slack_sdk.oauth (OAuth Flow Utilities)
• slack_sdk.socket_mode (Socket Mode client)
• slack_sdk.audit_logs (Audit Logs API client)
• slack_sdk.scim (SCIM API client)
• slack_sdk.rtm (RTM client)
• slack_sdk.signature (Request Signature Verifier)

[seratch]

Hi @AlexAtkinson, thank you so much for sharing this feedback and apologize for any inconvenience caused due to this limitation.

This has been one of the most common concerns about Slack's web APIs for a long time. Our Developer Relations team shares this sentiment and we are eager to implement some improvements such as adding a new API endpoint to look up channel IDs by their names. However, we're currently uncertain about the timeline for any solutions to come.

Though not ideal, a temporary workaround to ease the slow pagination calls is to use limit=1000 instead.

I've marked this issue as a server-side issue, and have excluded it from auto-triage workflow targets. Our team may be able to share updates on this here once something comes up. Thanks again for taking the time to write in.

[AlexAtkinson]

Tyvm. That is appreciated.

Note that supplying 1000 still results in the first page returning ~300, the next 80, 10, ... 0, 0....20, etc. It's very odd. I'd be interested to know what's in between the results?

[seratch]

Yeah, this is not intuitive at all… Please check my past reply at #1312 (comment) for details.