Org scoped searches disagree on what a deleted organization means

[rohilsurana]

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

1. Find out where the 404 for invoices and tokens comes from.
2. 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.
3. Apply it to SearchOrganizationUsers, SearchOrganizationProjects, SearchUserProjects and SearchOrganizationPATs.
4. Keep the SQL level live(organizations) checks from feat(store): org scoped searches report nothing for a deleted organization #1953 as well. They are cheap and they guard the case where a policy row outlives its organization. policies.resource_id has no foreign key to organizations, 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

• feat(store): org scoped searches report nothing for a deleted organization #1953 added the SQL level checks for three of these searches
• fix(store): a search value that is not a uuid reports bad input #1952 changed how a bad organization id is reported, which is what surfaced the split