GetOrganization returns 500 internal for a disabled org looked up by slug (200 by id)
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 344
- Forks
- 47
- Avg merge
- 4d 4h
- Merged PRs (30d)
- 26
Description
Summary
FrontierService.GetOrganization returns 500 internal when you look up a disabled org by its slug (name). The same org returns 200 when you look it up by id. This is a user facing RPC (frontier.proto), so it should never answer a known, expected condition with an internal error.
Behavior today
Called as a platform superuser against a disabled org:
| Lookup | HTTP | connect code | body |
|---|---|---|---|
| disabled org by slug | 500 | internal |
{"code":"internal","message":"internal server error"} |
| disabled org by id | 200 | - | returns the org (state: disabled) |
| enabled org by slug | 200 | - | returns the org |
| unknown slug | 404 | not_found |
- |
| unknown uuid | 403 | permission_denied |
- |
So the same disabled org gives 200 by id but 500 by slug. That is both a wrong status code and an inconsistency between the two ways to address the same org.
Why it matters
GetOrganizationis onFrontierServiceand is user facing. A500 internaltells clients "server bug" and is the wrong signal for a normal state (the org is disabled). Clients cannot handle it cleanly.- It leaks an internal error string path (
handleAuthErr: org is disabled) instead of a typed, documented error. - It breaks slug based deep links for disabled orgs. The admin UI slug URL work (#1763) resolves the URL segment through
GetOrganization. A disabled org opened by slug (refresh or bookmark) hits this 500 and the page cannot load.
Root cause
The RPC handler itself is fine. internal/api/v1beta1connect/organization.go GetOrganization calls orgService.GetRaw, which returns disabled orgs.
The 500 comes from the authorization step that runs before the handler:
pkg/server/connect_interceptors/authorization.gomapsGetOrganizationtohandler.IsAuthorized(Object{Namespace: organization, ID: req.GetId()}, GetPermission, req).req.GetId()is the raw URL segment, which can be a slug.internal/api/v1beta1connect/authorize.goIsAuthorizedcallsresourceService.CheckAuthz(...). Resolving the org by name rejects disabled orgs and returnsorganization.ErrDisabled. Resolving by id reads the graph directly and passes (disabled orgs stay authorized by id on purpose, per theDisableservice comment incore/organization/service.go).handleAuthErrmapsorganization.ErrNotExisttoCodeNotFound, butorganization.ErrDisabledis not handled and falls through to thedefaultbranch, which returnsCodeInternal.
// internal/api/v1beta1connect/authorize.go
func handleAuthErr(err error) error {
switch {
case errors.Is(err, user.ErrInvalidEmail) || errors.Is(err, errors.ErrUnauthenticated):
return connect.NewError(connect.CodeUnauthenticated, ErrUnauthenticated)
case errors.Is(err, organization.ErrNotExist),
errors.Is(err, project.ErrNotExist),
errors.Is(err, resource.ErrNotExist):
return connect.NewError(connect.CodeNotFound, ErrNotFound)
default: // organization.ErrDisabled lands here -> 500
return connect.NewError(connect.CodeInternal, fmt.Errorf("handleAuthErr: %w", err))
}
}
Expected behavior
No 500 for this case. Pick one, consistently for both id and slug:
- Preferred: let the authz name lookup treat disabled orgs the same as the id path, so
GetOrganizationreturns the disabled org for both id and slug. This matches the admin use case (a superuser can already read a disabled org by id) and removes the slug vs id split. - If reading a disabled org through this endpoint should be blocked, return a typed client error (for example
failed_precondition"org is disabled" ornot_found) for both id and slug, and stop returning the org by id too. Today the two paths disagree.
At minimum, handleAuthErr should recognize organization.ErrDisabled and map it to a proper client code instead of CodeInternal, so the endpoint never returns a 500 for a disabled org.
Steps to reproduce
- Create an org, then disable it (
DisableOrganization). - Call
GetOrganizationwith{"id": "<slug>"}as a superuser. Returns500 internal. - Call
GetOrganizationwith{"id": "<uuid>"}for the same org. Returns200withstate: disabled.
Related
Same pattern of user facing endpoints returning 500 instead of a proper client code: #1693, #1697.
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.
Research direction
Start with internal/api/v1beta1connect/authorize.go and pkg/server/connect_interceptors/authorization.go, then compare organization name and ID resolution in core/organization/service.go. Reproduce GetOrganization for a disabled organization by slug and ID, and make the endpoint return a consistent non-internal result for both paths without breaking the documented disabled-organization behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, authorization, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 64/100