fix(deleter): cascade service user delete on organization delete#1586
fix(deleter): cascade service user delete on organization delete#1586
Conversation
Service users belonging to a deleted organization were left orphaned in the serviceusers table — their credentials remained valid and the auth path returned a successful Principal for them after the parent org was gone. Add a service user cleanup step in DeleteOrganization between groups and roles; reuses serviceUserService.Delete which already removes credentials, org-membership policies, and SpiceDB relations. Refs: #1585 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe pull request extends the cascade deleter service to handle service user deletion during organization cascade operations. It introduces Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Review rate limit: 0/1 reviews remaining, refill in 60 minutes.Comment |
Coverage Report for CI Build 25154773359Coverage increased (+0.01%) to 41.963%Details
Uncovered Changes
Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
Summary
DeleteOrganizationdid not remove the service users owned by the org. Their rows lingered inserviceuserswithorg_idpointing at a deleted UUID, their credentials stayed inserviceuser_credentials, and the auth path happily continued to return aPrincipal{Type: ServiceUserPrincipal}for them. This PR adds the missing cleanup to the cascade deleter so that deleting an org actually deletes its service users (and their credentials and SpiceDB relations).Refs umbrella issue #1585.
Changes
ServiceUserServiceinterface and field oncore/deleter.Service(List,Delete).DeleteOrganizationbetween groups and roles: lists SUs byOrgIDand callsserviceUserService.Deleteper SU. Reuses the existing SU delete pipeline, which already removes credentials, org-membership policies, and SpiceDB tuples.cmd/serve.gowires the existingserviceUserServiceintoNewCascadeDeleter.core/deleterpackage added to.mockery.yaml;core/deleter/mocks/service_user_service.goregenerated.newMocksreturns the new mock; the full-cascade test asserts SU expectations; two new failure-path subtests cover SU list and SU delete error propagation.Technical Details
Why between groups and roles in the cascade? The existing order is policies → projects → groups → SUs (new) → roles → invitations → billing → org. Service users are principals owned by the org (like groups), so they sit alongside groups in the cascade. Placing them after the bulk policy delete is fine:
serviceUserService.DeleteinvokesRemoveOrganizationMember, which is best-effort and logs a warning if the policy is already gone.No database FK added in this PR. A complementary
serviceusers.org_idFK withON DELETE RESTRICTis intentionally deferred. It needs a one-time backfill for any pre-existing orphaned rows; tracking that separately keeps this PR small and shippable.No proto / API changes. This is a purely internal correctness fix in the cascade deleter.
Test Plan
go test ./core/deleter/...passesgo build ./core/deleter/... ./cmd/...DeleteOrganization, verify SU row, credential rows, and SpiceDB tuples are gone, and that the credential no longer authenticates🤖 Generated with Claude Code