用户编辑抽屉可能被过期用户详情请求覆盖
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 72/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- typescript
- Domain
- frontend
Research direction
Open web/default/src/features/users/components/users-mutate-drawer.tsx and start at the update-drawer getUser(currentRow.id) call. Reproduce the rapid A-to-B switch with a delayed request, then verify that a response for a previous user or a cleaned-up effect no longer changes the current form.
Written by the indexing model from the issue text.
Description
提交前必读(请勿删除本节)
- 文档:https://docs.newapi.ai/
- 使用问题先看或先问:https://deepwiki.com/QuantumNous/new-api
- 警告:删除本模板、删除小节标题或随意清空内容的 issue,可能会被直接关闭;重复恶意提交者可能会被 block。
您当前的 newapi 版本
main 分支 15880270,通过代码审计确认。
提交确认
- 我已确认目前没有类似 issue
- 我已完整查看过文档 https://docs.newapi.ai/ 和项目 README,尤其是常见问题部分
- 我未删除此模板中的任何引导内容或小节标题,并会按要求完整填写
- 我理解项目维护者精力有限,不遵循模板要求的 issue 可能会被无视或直接关闭
问题描述
管理员用户编辑抽屉在打开编辑已有用户时,会异步调用用户详情接口刷新表单。如果管理员快速从用户 A 切换到用户 B,且用户 A 的请求返回较慢,A 的旧响应仍可能重置当前抽屉表单,导致 B 的编辑抽屉短暂显示或使用 A 的数据。
相关代码在 web/default/src/features/users/components/users-mutate-drawer.tsx:打开更新抽屉后直接调用 getUser(currentRow.id).then(...),但返回时没有校验响应是否仍属于当前选中的用户,也没有在 effect cleanup 后忽略旧请求。
复现步骤
- 进入管理员用户列表。
- 打开用户 A 的编辑抽屉,并让
/api/user/A请求延迟返回(例如浏览器 devtools throttling 或 mock 接口延迟)。 - 在用户 A 请求返回前,切换打开用户 B 的编辑抽屉。
- 等用户 A 的旧请求返回。
- 观察当前抽屉表单可能被用户 A 的旧响应覆盖。
预期结果
只有当前选中用户对应的详情响应可以更新抽屉表单。旧用户请求返回时,如果抽屉已经切换用户或 effect 已清理,应忽略该响应。
相关截图
无。该问题属于异步请求竞态,代码路径和复现步骤如上。
- Dominant language
- Go
- Stars
- 48.5k
- Forks
- 11.6k
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 61
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from QuantumNous/new-api
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
QuantumNous/new-api#7511 · 1 comment ·
-
fix(relay): terminal stream chunk with finish_reason is dropped when client does not request usage Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
QuantumNous/new-api#7489 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
QuantumNous/new-api#7479 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
QuantumNous/new-api#7467 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
QuantumNous/new-api#7417 · 1 comment ·
All issues in QuantumNous/new-api
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
enhancement needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
kind/cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
kubernetes-sigs/kueue#15947 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100