Claim Member#invite_email in the Topology Service
What does this MR do and why?
Register Member#invite_email as a claimable attribute in the
Topology Service
so the HTTP Router can route invitation sign-in flows (e.g.
/users/sign_in?invite_email=foo@example.com) to the cell that owns
the inviting organization.
Part of &650.
What's claimed
| Property | Value |
|---|---|
| Bucket type | INVITE_EMAILS |
| Bucket value | member.invite_email |
| Subject type | NAMESPACE |
| Subject id | member.member_namespace_id |
| Source type | RAILS_TABLE_MEMBERS |
The new INVITE_EMAILS bucket type and RAILS_TABLE_MEMBERS source
type were added to the proto in gitlab-org/cells/topology-service!513 (merged),
and pulled into this repo via the gem update. (As explained in gitlab-org/cells/topology-service!513 (merged))
Bulk-write claim cleanup
Member#invite_email rows are deleted in bulk by
RemoveUnacceptedMemberInvitesWorker when invitations expire (90
days). delete_all skips ActiveRecord callbacks, so without
intervention every expired invite would leave a stale claim in the
Topology Service.
This MR updates the worker to:
- Load the batch of expiring invitations into memory using
Member.cells_claims_scope(which narrows theSELECTto only claim-relevant columns, keeping per-batch memory bounded). - Build destroy metadata via the standard
build_destroy_metadata_for_worker(:invite_email)helper. - Re-apply the
.invite.where(user_id: nil)predicate atDELETEtime. This preserves the original safety guarantee against deleting invites that get accepted betweenSELECTandDELETE. - Enqueue
Cells::BulkClaimsWorkerslices of up toBULK_CLAIMS_BATCH_SIZE(500) entries each.
When cells_claims_members is disabled (current state), the worker
short-circuits the metadata build and behaves identically to today.
Feature flags
| Flag | Type | Purpose |
|---|---|---|
cells_claims_members |
gitlab_com_derisk |
Gates the after_save / bulk-cleanup claim emission for Member#invite_email |
cells_claims_verification_worker_member |
gitlab_com_derisk |
Gates the periodic verification reconciliation for the Member model |
Both default to false.
References
- gitlab-com/gl-infra/tenant-scale/cells-infrastructure/team#650
- Docs on adding a claim attribute https://docs.gitlab.com/development/cells/claims/#rails
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.