[Bug] Service API GET segments sets has_more incorrectly (breaks when limit > 100)

问题场景

用户在使用 Dify 的 Service API 获取数据集文档分段时触发，具体路径为 GET /v1/datasets/{dataset_id}/documents/{document_id}/segments。当文档包含超过 100 个分段（例如 150 个），且请求参数 limit=200 时，响应中 has_more 字段错误地为 false，导致客户端认为已无更多数据而提前停止拉取。

报错原文

[Bug] Service API GET segments sets has_more incorrectly (breaks when limit > 100)
"has_more": len(segments) == limit

原因分析

问题根源在于 api/controllers/service_api/dataset/segment.py 文件中的 SegmentApi.get 方法。该方法直接从查询参数读取 limit 值且未做上限钳制，然后将其用于 has_more 的判断表达式。然而，底层 SegmentService.get_segments 内部委托的 paginate_query 函数会执行钳制逻辑 per_page = min(per_page, max_per_page)，其中 max_per_page=100。因此当请求 limit=200、实际 total=150 时，服务端实际只返回 100 行数据，但响应中计算 100 == 200 为 False，导致 has_more 错误地设为 false，尽管还有 50 个分段未被返回。同时，当最后一页恰好返回正好 limit 条数据时，has_more 又会错误地变成 true，迫使客户端执行一次多余的空请求。

环境排查

• 确认 Dify 版本是否为 main (1.17.x) 或更高版本。
• 确认部署方式是否为 Self Hosted (Docker)。
• 检查 api/libs/pagination.py 中 max_per_page 是否仍为 100。
• 排查请求中 limit 参数是否超过 100。

解决步骤

1. 临时规避：将请求中的 limit 参数设置为小于等于 100 的值（如 limit=100），可暂时避免触发该问题。
2. 临时规避：根据响应中 total 字段与当前页已获取的数据量判断是否继续请求，而不是依赖 has_more 字段。
3. 等待官方修复或自行修改源码：在 SegmentApi.get 中，将 limit 钳制后再进行比较，例如使用 effective_limit = min(limit, 100)，然后计算 has_more = len(segments) == effective_limit，并在响应中返回钳制后的 limit 值。此修复方案与同文件中 ChildChunkApi.get 的实现方式保持一致，尚未有官方 PR 验证，可优先尝试。
4. 注意检查同文件中数据集列表接口和文档列表接口是否存在相同代码模式，若有需一并修复。

验证方法

创建一个包含 150 个分段的文档，调用 Service API 请求分段列表，设置 page=1&limit=200，确认响应中返回的 data 长度为 100（受服务端钳制），且 has_more 正确为 true，继续请求第二页可以获取剩余数据。

参考来源

langgenius/dify #41775

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。