Groups pagination multiplies the offset twice, causing empty pages after page 1
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 74/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- typescript
调研方向
从 Groups 路由文件 apps/start/src/routes/_app.$organizationId.$projectId.groups.tsx 第 52 行附近开始，那里计算了 cursor，然后与 group.service.ts 第 140 行附近对比，那里的偏移量是 cursor * take。检查 Profiles 页面在相同约定下如何计算 cursor。当第 2 页发送 cursor=1 并返回接下来的 50 个分组，且 Group Members 页面的 cursor 不匹配问题已修复或确认不在范围内时，即视为完成。
由索引模型根据 Issue 内容生成。
描述
Description
The Groups list shows data on page 1, but subsequent pages are empty even though more groups exist.
I reproduced this in production. Manually changing the pagination parameters returns the expected data.
Steps to reproduce
- Open the Groups list in a project with more than 100 groups, for example 120.
- Navigate to page 2 or page 3.
- Inspect the
/api/trpc/group.listrequests:- Page 2 sends
take=50, cursor=50. - Page 3 sends
take=50, cursor=100.
- Page 2 sends
- Replay the requests with
cursor=1andcursor=2, respectively. Both return data in my production instance.
Expected behavior
With a page size of 50:
- Page 2 should skip 50 rows.
- Page 3 should skip 100 rows.
Root cause
The Groups frontend sends:
cursor: (page - 1) * PAGE_SIZE
The backend calculates:
OFFSET = cursor * take
This produces offsets of 2500 and 5000 instead of 50 and 100.
The Profiles frontend correctly sends cursor: page - 1, using the same backend pagination convention.
Suggested fix
Change the Groups frontend to cursor: page - 1.
The Group Members page has the same parameter mismatch based on source inspection, but I have not tested that page in production.
Environment
- Deployed version / image digest: [fill in]
- Source inspected: v2.3.0 and main at 7c4d22a
Source references
- 主要语言
- TypeScript
- 星标
- 7.1k
- 派生
- 516
- 平均合并
- 4 天 40 分钟
- 30 天内合并 PR
- 4
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
Openpanel-dev/openpanel 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
Openpanel-dev/openpanel#543 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 88/100
Openpanel-dev/openpanel#532 ·
维护者通常 1 天内回复
-
Period comparison badge shows wrong percentage for decreases (100 → 50 shows ↓100%)可能已有人在做 @sarmah-rup 于 18 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 85/100
Openpanel-dev/openpanel#526 ·
维护者通常 1 天内回复
-
Self-hosted missing op1-replay.js可能已有人在做 @houstona 于 18 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 84/100
Openpanel-dev/openpanel#512 · 1 条评论 ·
维护者通常 1 天内回复
-
login page needs refinement可能已有人在做 @anandghegde 于 32 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 68/100
Openpanel-dev/openpanel#495 ·
维护者通常 1 天内回复
查看 Openpanel-dev/openpanel 的全部 Issue
相似的 Issue
-
Endpoint links in the tag operations list are below the 24px target size可能已有人在做 @AdzerKI 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
ai-driven-qa bug Minor
难度 2/5 1-3 小时 新手友好度 80/100
linagora/twake-tasks#435 ·
维护者通常 1 天内回复
-
bug domain: database priority: p1 Stellar Wave
难度 2/5 1-3 小时 新手友好度 74/100
StellarState/SS-backend#632 · 1 条评论 ·
维护者通常 1 天内回复
-
A2A audit timestamps end in +00:00Z (invalid ISO 8601)可能已有人在做 @O1sumitkumar 今天认领。 未关闭bug good first issue help wanted python
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
`cf complete zsh >> .zshrc` fails on vanilla zsh可能重新可做 关联的 PR 已关闭且未合并。 未关闭
难度 2/5 1-3 小时 新手友好度 75/100
cloudflare/cf#340 ·
维护者通常 1 天内回复