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:

  1. Load the batch of expiring invitations into memory using Member.cells_claims_scope (which narrows the SELECT to only claim-relevant columns, keeping per-batch memory bounded).
  2. Build destroy metadata via the standard build_destroy_metadata_for_worker(:invite_email) helper.
  3. Re-apply the .invite.where(user_id: nil) predicate at DELETE time. This preserves the original safety guarantee against deleting invites that get accepted between SELECT and DELETE.
  4. Enqueue Cells::BulkClaimsWorker slices of up to BULK_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

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.

Edited by Marco Gregorius

Merge request reports

Loading