Org scoped searches disagree on what a deleted organization means
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 68/100
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- Go
- Star
- 344
- Fork
- 47
- Merge trung bình
- 2 ngày 20 giờ
- Pull request đã merge (30 ngày)
- 39
Chuẩn bị môi trường
Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. Hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của raystack/frontier
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 58/100
Maintainer thường phản hồi trong vòng 1 ngày
-
authz bug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 70/100
raystack/frontier#1896 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Add OpenTelemetry tracingĐang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 45/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 38/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của raystack/frontier
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
NVIDIA/k8s-device-plugin#2076 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 1 ngày
-
agentic-workflows
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
area/release kind/bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
kubernetes-sigs/kueue#16455 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày