fix(invitation): remove user relation on invitation delete

[whoAbhishekSah]

What

Invitation creation writes two SpiceDB tuples anchored on the invitation object:

• app/invitation:<id>#user@app/user:<email>
• app/invitation:<id>#org@app/organization:<org>

Invitation.Delete filtered the relation delete by the org relation name only, so the #user tuple was left behind on every accept, expire, and delete. These orphan tuples accumulated in SpiceDB over time.

Fix

Drop the RelationName filter in Delete so it removes every relation anchored on the invitation object (the same pattern role.Delete already uses). Accept already routes its cleanup through Delete, so accept is covered too.

Test

Extends the existing TestInvitationAPI accept flow with an assertion that, after accepting an invitation, ListRelations returns no relation on the invitation object. Verified the assertion fails without the fix (leftover #user tuple) and passes with it.

Addresses gap (3) of #1661.

[vercel]

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

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

[coderabbitai]

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: 43afdbe6-eb92-44d5-b557-1cbf30eedc86

📥 Commits

Reviewing files that changed from the base of the PR and between bd6a145 and 47109aa.

📒 Files selected for processing (2)

• core/invitation/service.go
• test/e2e/regression/api_test.go

---

📝 Walkthrough

Summary by CodeRabbit

• Bug Fixes

  • Improved invitation cleanup to ensure all associated data is properly removed when invitations are deleted, accepted, or expire, preventing orphaned records from lingering in the system.

• Tests

  • Added regression test to verify complete cleanup of invitation-related data during acceptance workflows.

Walkthrough

This PR fixes a relation leakage bug in invitation deletion where the user relation tuple was not being cleaned up. The implementation change broadens relation deletion to remove both user and org tuples, and a regression test verifies the fix works correctly after invitation acceptance.

Changes

Invitation relation cleanup fix

Layer / File(s)	Summary
Service.Delete relation cleanup fix core/invitation/service.go	Service.Delete now calls relationService.Delete with only the invitation object, removing the RelationName restriction that previously matched only the organization tuple. Inline comments document that both user and org tuples are written by createRelations and that omitting RelationName prevents user tuple leakage on accept, expire, or delete.
Invitation acceptance relation cleanup regression test test/e2e/regression/api_test.go	After AcceptOrganizationInvitation, the test queries the admin client for SpiceDB relations tied to the invitation object and asserts the set is empty, verifying both user and org tuples are properly cleaned up.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested reviewers

• rohilsurana
• rohanchkrabrty

🚥 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

• X
• Mastodon
• Reddit
• LinkedIn

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

[coveralls]

Coverage Report for CI Build 27010255188

Coverage increased (+0.005%) to 43.226%

Details

• Coverage increased (+0.005%) from the base build.
• Patch coverage: 4 of 4 lines across 1 file are fully covered (100%).
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	38049
Covered Lines:	16447
Line Coverage:	43.23%
Coverage Strength:	12.14 hits per line

---

💛 - Coveralls