API Cursor Pagination Performance : conversations.list
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- python
调研方向
从 slack_sdk.web.WebClient 中 conversations.list、chat.update 和 chat.postMessage 的入口点开始,然后检查游标分页和频道名称处理是如何提供的。该 issue 提出了多种可能的解决方案,因此完成标准是选择并明确 SDK 应直接解析名称、优化分页,还是统一消息方法,并通过测试覆盖所选行为。
由索引模型根据 Issue 内容生成。
描述
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)
- 主要语言
- Python
- 星标
- 4k
- 派生
- 857
- 平均合并
- 22 小时 21 分钟
- 30 天内合并 PR
- 16
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
slackapi/python-slack-sdk 的其他 Issue
-
needs info server-side-issue
难度 4/5 3-5 天 新手友好度 35/100
slackapi/python-slack-sdk#1961 · 3 条评论 ·
-
Use logger.isEnabledFor(logging.DEBUG) instead of logger.level <= logging.DEBUG for debug guards 未关闭auto-triage-skip bug
难度 4/5 3-5 天 新手友好度 55/100
slackapi/python-slack-sdk#1957 ·
-
auto-triage-skip discussion
难度 5/5 一周以上 新手友好度 35/100
slackapi/python-slack-sdk#1940 · 2 条评论 ·
-
chat_postMessage silently forwards thread_id to the API, so a threaded reply posts to the channel 未关闭auto-triage-skip enhancement
难度 4/5 3-5 天 新手友好度 48/100
slackapi/python-slack-sdk#1923 · 2 条评论 ·
-
auto-triage-skip bug socket-mode
难度 3/5 1-2 天 新手友好度 72/100
slackapi/python-slack-sdk#1922 · 2 条评论 ·
查看 slackapi/python-slack-sdk 的全部 Issue
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 75/100
stephrobert/dsoxlab#238 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 2/5 1-3 小时 新手友好度 75/100
sublimehq/package_control#1780 ·
-
难度 2/5 1-3 小时 新手友好度 65/100
-
难度 2/5 1-3 小时 新手友好度 70/100
nwg-piotr/nwg-displays#145 ·