Skip to content

fix(role): reject deletion of a role still in use by policies#1683

Merged
whoAbhishekSah merged 1 commit into
mainfrom
fix/role-delete-cascade-policies
Jun 9, 2026
Merged

fix(role): reject deletion of a role still in use by policies#1683
whoAbhishekSah merged 1 commit into
mainfrom
fix/role-delete-cascade-policies

Conversation

@whoAbhishekSah

@whoAbhishekSah whoAbhishekSah commented Jun 8, 2026

Copy link
Copy Markdown
Member

Problem

Deleting a role touches two stores: SpiceDB (the role's permission tuples) and Frontier's Postgres roles table (the role row). The old order was: delete the SpiceDB tuples first, then delete the row in Postgres.

But the Postgres policies table has a foreign key to roles, so if a policy still uses the role, the Postgres row delete fails — after the SpiceDB tuples were already removed. Result: a broken role that still exists in Postgres but grants nothing in SpiceDB, plus a confusing 500.

Change

Deleting a role now fails cleanly if the role is still used by any policy:

  • Delete the Postgres roles row first; only remove the SpiceDB permission tuples if that succeeds.
  • A role still referenced by a policy is rejected with FailedPrecondition and the message "role is in use by one or more policies" — neither store is touched.
  • To delete such a role, remove its policies first. (Deleting a policy already cleans up its own SpiceDB tuples, including the link back to the role.)

We don't auto-delete the policies, because that would silently revoke access for everyone using the role and could be a lot of deletes in one request.

Tests

  • Unit: role in use → returns the error, SpiceDB untouched; role not in use → Postgres row deleted, then its SpiceDB tuples cleaned.
  • e2e (TestOrganizationRoleDeleteInUse): deleting an in-use role is rejected and nothing is torn down; after the policy is removed, the role deletes cleanly with no leftover SpiceDB tuples.

Addresses gap (1) of #1661.

@vercel

vercel Bot commented Jun 8, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
frontier Ready Ready Preview, Comment Jun 9, 2026 5:56am

@coderabbitai

coderabbitai Bot commented Jun 8, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 8a01a375-1ca5-4e7c-8abd-75a9a3cd1b4c

📥 Commits

Reviewing files that changed from the base of the PR and between d688fd7 and e2f2d58.

📒 Files selected for processing (6)
  • core/role/errors.go
  • core/role/service.go
  • core/role/service_test.go
  • internal/api/v1beta1connect/role.go
  • internal/store/postgres/role_repository.go
  • test/e2e/regression/api_test.go
✅ Files skipped from review due to trivial changes (1)
  • core/role/errors.go

📝 Walkthrough

Summary by CodeRabbit

  • Bug Fixes
    • Prevented deletion of roles referenced by existing policies. Attempting to delete an in-use role now returns a clear error and no changes are made, requiring policy bindings to be removed first.

Walkthrough

The PR prevents deletion of roles that are referenced by policies. It defines a new ErrRoleInUse error, detects foreign key violations when the repository attempts to delete role rows, reorders service deletion to check constraints before tuple cleanup, maps the error to HTTP FailedPrecondition responses, and validates the full flow with unit and end-to-end tests.

Changes

Role deletion with in-use constraint

Layer / File(s) Summary
Error definition and FK constraint detection
core/role/errors.go, internal/store/postgres/role_repository.go
Defines ErrRoleInUse error and updates repository layer to catch Postgres foreign key violations on policies.role_id and return the new error instead of generic handler.
Service deletion with ID resolution and constraint check
core/role/service.go, core/role/service_test.go
Reworks Service.Delete to resolve the input ID to a full role record, delete the role row first (triggering FK constraint check), and then clean up permission tuples using the resolved ID. Unit tests validate both the rejection and success paths.
API error response mapping
internal/api/v1beta1connect/role.go
Updates DeleteOrganizationRole and DeleteRole handlers to explicitly map role.ErrRoleInUse to connect.CodeFailedPrecondition response code.
End-to-end regression test
test/e2e/regression/api_test.go
Adds TestOrganizationRoleDeleteInUse that verifies deletion is rejected while referenced by a policy, no tuples are removed on rejection, and deletion succeeds after policy removal with full cleanup of permission tuples.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested reviewers

  • rohilsurana
  • AmanGIT07
🚥 Pre-merge checks | ✅ 2
✅ Passed checks (2 passed)
Check name Status Explanation
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ 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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@coveralls

coveralls commented Jun 8, 2026

Copy link
Copy Markdown

Coverage Report for CI Build 27186856054

Coverage increased (+0.01%) to 43.495%

Details

  • Coverage increased (+0.01%) from the base build.
  • Patch coverage: 8 uncovered changes across 2 files (10 of 18 lines covered, 55.56%).
  • No coverage regressions found.

Uncovered Changes

File Changed Covered %
internal/api/v1beta1connect/role.go 4 0 0.0%
internal/store/postgres/role_repository.go 4 0 0.0%
Total (3 files) 18 10 55.56%

Coverage Regressions

No coverage regressions found.


Coverage Stats

Coverage Status
Relevant Lines: 38103
Covered Lines: 16573
Line Coverage: 43.5%
Coverage Strength: 12.19 hits per line

💛 - Coveralls

@whoAbhishekSah whoAbhishekSah force-pushed the fix/role-delete-cascade-policies branch from d688fd7 to 8772c28 Compare June 8, 2026 05:35
@whoAbhishekSah whoAbhishekSah marked this pull request as draft June 8, 2026 06:03
@whoAbhishekSah whoAbhishekSah force-pushed the fix/role-delete-cascade-policies branch from 8772c28 to 69a3d6c Compare June 8, 2026 07:55
@whoAbhishekSah whoAbhishekSah force-pushed the fix/role-delete-cascade-policies branch from 69a3d6c to a1f47f4 Compare June 9, 2026 04:29
@whoAbhishekSah whoAbhishekSah force-pushed the fix/role-delete-cascade-policies branch from 1daa527 to 68e04f1 Compare June 9, 2026 05:45
@whoAbhishekSah whoAbhishekSah changed the title fix(role): cascade policy + rolebinding cleanup on role delete fix(role): reject deletion of a role still in use by policies Jun 9, 2026
@whoAbhishekSah whoAbhishekSah force-pushed the fix/role-delete-cascade-policies branch from 68e04f1 to ac2dcec Compare June 9, 2026 05:49
Deleting a role used to strip its app/role:<id>#<perm>@* tuples from SpiceDB
*before* the row delete. Because policies.role_id has a foreign key to
roles(id) with no ON DELETE rule, deleting an in-use role then failed the
row delete with an opaque 500 — after the permission tuples were already
gone, leaving a half-deleted role that still existed but granted nothing.

Make role deletion a clean guard instead of a destructive cascade: attempt
the row delete first, and only remove the permission tuples once it
succeeds. The role repository maps the foreign-key violation to a new
role.ErrInUse, which the handlers return as FailedPrecondition. Deleting a
role that still has policies is therefore rejected with a clear message and
zero side effects; the caller must remove those policies first.

This intentionally avoids cascading policy deletion, which would revoke
access for every principal granted the role and, for a widely-assigned
role, fan out into many serial SpiceDB deletes inside one request.

Adds unit tests for the in-use rejection / clean-delete paths and an e2e
test asserting an in-use role can't be deleted (FailedPrecondition, nothing
torn down) and deletes cleanly once its policy is removed.

Refs #1661

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@whoAbhishekSah

Copy link
Copy Markdown
Member Author

Manual verification ✅

Tested the DeleteOrganizationRole flow against a local build of this branch (live ConnectRPC server + SpiceDB), following the same scenario as the TestOrganizationRoleDeleteInUse e2e test.

Setup: created an org, a custom role (in_use_role, perm app.organization.grouplist), a user, and a policy binding the role to the user on the org. At this point the role had 3 SpiceDB permission tuples and the policy had 2 rolebinding tuples.

Step Action Expected Result
1 Delete role while a policy still uses it rejected, nothing torn down FailedPrecondition — "role is in use by one or more policies" (HTTP 400)
2 Re-fetch role + recount tuples after the failed delete role intact ✅ role still exists (200), perm tuples still 3 — no SpiceDB tuples touched
3 Delete the policy succeeds, rolebinding tuples cleared ✅ 200, rolebinding tuples → 0
4 Delete the (now unused) role succeeds ✅ 200
5 Re-fetch role + recount tuples after delete gone, no leftovers ✅ role 404, perm tuples → 0

Confirms the fix end-to-end: the FK guard fires before any SpiceDB tuples are removed (no more half-deleted role / opaque 500), the error surfaces cleanly as FailedPrecondition, and once the policy is gone the role deletes with no leftover tuples.

@whoAbhishekSah whoAbhishekSah marked this pull request as ready for review June 9, 2026 06:20
@whoAbhishekSah whoAbhishekSah merged commit b96f141 into main Jun 9, 2026
8 checks passed
@whoAbhishekSah whoAbhishekSah deleted the fix/role-delete-cascade-policies branch June 9, 2026 06:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants