bug: Slack Integration Breaks if Slack API returns a 429

快速结论：当 Slack 工作空间包含大量频道时，Langfuse 的 Slack 集成会在拉取频道列表时触发 Slack API 的 429 限流错误，且客户端未正确解析 Retry-After 头部导致永久故障。优先排查 SLACK_FETCH_LIMIT 环境变量值并尝试降低至 50。

问题场景

用户在自托管 Langfuse 环境（self-hosted）中完成 Slack 身份认证后，频道列表始终无法加载。检查 Pod 日志发现 Slack 的 webClient 持续返回 429（Too Many Requests）错误，且一旦触发该错误，客户端永久无法恢复。降低环境变量 SLACK_FETCH_LIMIT 至 50 后可临时解决。

报错原文

Slack's webClient was reporting 429 errors.
Once this happens LF/webClient never recovers, presumably because the Retry-After value isn't respected.

原因分析

可能原因：WebClient 在实例化时仅传入了 bot token，未配置自定义 retryConfig，导致默认重试机制未正确识别 429 响应中的 Retry-After 头部。此外，getChannelsRecursive() 方法的 try/catch 结构在分页请求遇到 429 时，只是静默捕获错误并返回部分结果（甚至空结果），而非触发重试。同时，默认的 SLACK_FETCH_LIMIT 为 5,000，每次分页批次大小为 200，可能连续发起多达 25 次 API 请求，极易触发 Slack 的速率限制。

环境排查

确认 Langfuse 版本是否为 latest（Issue 中用户使用 latest 版本）
检查 SLACK_FETCH_LIMIT 环境变量的当前配置值（默认 5000，定义于 env.ts 第 266–273 行）
检查 Pod（容器）日志中是否存在 429 状态码记录
确认 Slack 工作空间的频道总数，尤其是超过 200 个频道的大规模场景
确认 @slack/web-api 版本是否为 v7（该版本内置了默认重试机制，但未针对 429 做专门处理）

解决步骤

临时降低 SLACK_FETCH_LIMIT：在环境变量中将 SLACK_FETCH_LIMIT 设为 50，减少单次拉取的频道数量，降低 API 请求频率。
检查重试配置（可优先尝试）：确认是否可以在 SlackService.ts（第 283 行附近）实例化 WebClient 时传入自定义 retryConfig，明确启用基于 Retry-After 头部的重试策略。
修改分页逻辑：在 getChannelsRecursive() 方法（第 340–345 行）中，添加分页请求之间的固定延迟（如 1-2 秒），避免突发调用。同时在 catch 块中专门处理 ratelimited 错误，调用重试逻辑而非直接返回空/部分结果。
作为备选方案：在用户界面中允许手动输入 Slack 频道名称（带格式验证），绕过自动拉取列表功能。