issue: GET /api/v1/analytics/users: skip query parameter ignored

快速结论：该报错出现在通过自动化流程（如 n8n）调用 Open WebUI 的用户分析接口 GET /api/v1/analytics/users 时：skip 参数被静默忽略，且不传 limit 时结果被静默截断为 50 条，导致下游统计失真。优先排查调用方是否依赖了 skip 分页，以及是否显式传入了足够的 limit。

适用环境：Issue 未提供具体 Open WebUI 版本、操作系统或 Python 环境。已确认的调用方式为带 Authorization: Bearer $API_KEY 的 HTTP 请求，调用方为基于 n8n 构建的分析管道。

最快修复方案：暂无确认的一步修复方案。Issue 中讨论的 skip 语义、分页元数据与文档化默认 limit 均为期望行为，并未在讨论链中确认已修复。

注意事项：Issue 中给出的临时做法是显式传 limit=1000，但这只是把截断上限抬高，并未解决 skip 无效的问题，用户量超过该值后仍会静默截断；该上限是否为硬性约束，Issue 中未给出明确结论。

问题场景

用户使用 Open WebUI 的 REST API 结合 n8n 搭建每日用户数统计管道，按日期范围调用 GET /api/v1/analytics/users 拉取用户数据。为了分批取数，调用方使用了 skip + limit 做偏移分页，但发现不同 skip 值返回的结果完全一致；在不带 limit 时，返回条数恰好停在 50，导致首日用户数正好落在 50 这一可疑数值上，下游统计因此出现偏差。

报错原文

issue: GET /api/v1/analytics/users: skip query parameter ignored

# Same date range, only skip differs → byte-identical responses
GET /api/v1/analytics/users?start_date=1793059200&end_date=1793145599&limit=50&skip=0
GET /api/v1/analytics/users?start_date=1793059200&end_date=1793145599&limit=50&skip=50

# No limit parameter → exactly 50 results returned (default cap, silently)
GET /api/v1/analytics/users?start_date=1793059200&end_date=1793145599

原因分析

最可能的原因是后端该接口的查询逻辑没有把 skip 参数应用到结果集偏移上，同时对 limit 缺少非法值或缺失值的处理：未传 limit 时回落到默认值 50，且被超过某个上限的值（如 limit=1000）截断时没有任何错误提示或截断标记。调用方因此既无法判断分页是否生效，也无法感知结果被截断。

另有一种可能原因是：该接口在设计上本就不支持偏移分页，skip 属于未实现的参数而被静默吞掉，而非被拒绝。Issue 正文本身也提出了这一可能性，但讨论链未给出结论。

环境排查

确认 Open WebUI 的实际部署版本，并对照 dev 分支或最新源码中该接口的实现（Issue 标题标记为已解决，但讨论链未附修复说明）。
确认调用端（n8n 或脚本）是否在每次请求中都显式传入了 limit，以及是否依赖 skip 实现翻页。
确认 start_date / end_date 的实际时间范围与用户总量，用于判断 50 条或 1000 条是否恰好是截断点。
Issue 未提供操作系统、Python、依赖版本或显卡信息，无需在此类项目上排查。

解决步骤

先复现：用相同日期范围分别请求 skip=0 与 skip=50，对比响应是否逐字节一致，确认 skip 是否确实无效。
补一次不带 limit 的请求，记录返回条数是否为 50，确认默认截断行为。
可优先尝试的规避方案：在调用中显式传入一个足够大的 limit（Issue 中验证过 limit=1000 可返回至多 1000 条），并确保该值覆盖当前日期范围内的用户总量。
由于 skip 无效，不要依赖偏移分页来拼接结果；改为按日期区间切分请求，或将单次返回条数与已知用户总量做比对以发现截断。
在调用端增加结果条数校验：当返回条数等于所用 limit 值（或等于 50）时，视为可能被截断并告警，避免下游统计静默出错。
升级 Open WebUI 到已包含该 Issue 修复的版本后重新验证；若当前已是最新版仍复现，可在原 Issue 下补充请求日志与版本信息。

验证方法

在同一日期范围下用 skip=0 与 skip=50 各请求一次，确认两次返回不再重复、能覆盖不同的用户集合；同时确认不带 limit 时返回的条数与你对当前用户总量的预期一致，或响应中出现了可用于判断截断的分页信息。最后核对下游统计中的每日用户数不再固定落在 50 或 limit 边界值上。