Org scoped searches disagree on what a deleted organization means
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Trace the handlers and aggregate services for the invoice and token RPCs first to find where their 404 responses originate, then compare that path with the other org-scoped searches and OrganizationRepository.Delete. Make every listed search resolve the organization consistently and return 404 when absent while retaining the SQL live(organizations) checks; verify the behavior for all affected RPCs.
由索引模型根据 Issue 内容生成。
描述
The problem
Asking an org scoped search about an organization that is gone gives different answers depending on which RPC you call. A client cannot tell "this organization does not exist" apart from "this organization has nothing to show".
We want 404 not found everywhere.
Where things stand today
Verified by reading the handlers and services:
| RPC | Today | How |
|---|---|---|
SearchOrganizationServiceUsers |
404 | The handler calls orgService.GetRaw first, which reads live rows only |
SearchOrganizationUsers |
200, empty list | After #1953 the SQL filters the organization out |
SearchOrganizationProjects |
200, empty list | After #1953 the SQL filters the organization out |
SearchUserProjects |
200, empty list | After #1953 the SQL filters the organization out |
SearchOrganizationPATs |
200, with rows | No check anywhere. See the comment on #1953 |
SearchOrganizationInvoices |
404 | Needs confirming, see below |
SearchOrganizationTokens |
404 | Needs confirming, see below |
The end to end run in #1952 reported 404 for invoices and tokens. But neither handler nor either aggregate service resolves the organization. So something upstream is doing it, and part of this work is finding out what. If it turns out to be a shared path, that path may be the right place to fix all of them at once.
What to do
- Find out where the 404 for invoices and tokens comes from.
- Pick one way for every org scoped search to resolve the organization before running the query, and answer 404 when it is not there. Reuse whatever invoices and tokens already go through if that turns out to be shared.
- Apply it to
SearchOrganizationUsers,SearchOrganizationProjects,SearchUserProjectsandSearchOrganizationPATs. - Keep the SQL level
live(organizations)checks from #1953 as well. They are cheap and they guard the case where a policy row outlives its organization.policies.resource_idhas no foreign key toorganizations, so a hard deleted organization does leave membership policies behind.
Why it matters
Today OrganizationRepository.Delete is a hard delete and nothing sets deleted_at on organizations, so the split is mostly invisible. It will stop being invisible the moment organizations get a soft delete. Better to settle it now while the blast radius is small.
Related
- #1953 added the SQL level checks for three of these searches
- #1952 changed how a bad organization id is reported, which is what surfaced the split
- 主要语言
- Go
- 星标
- 344
- 派生
- 47
- 平均合并
- 2 天 20 小时
- 30 天内合并 PR
- 39
环境准备
我们还没有检查这个项目的环境配置文件。先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
raystack/frontier 的其他 Issue
-
难度 4/5 3-5 天 新手友好度 58/100
维护者通常 1 天内回复
-
authz bug
难度 3/5 1-2 天 新手友好度 70/100
raystack/frontier#1896 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 45/100
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 38/100
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 75/100
维护者通常 1 天内回复
查看 raystack/frontier 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 88/100
gruntwork-io/boilerplate#329 ·
-
难度 2/5 1-3 小时 新手友好度 65/100
prime-radiant-inc/evener#3291 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 72/100
Netcracker/qubership-apihub-backend#582 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 86/100
维护者通常 1 天内回复