Drop abuse_report_user_mentions table

What does this MR do and why?

Drops the dead abuse_report_user_mentions table. This is step 3 of 3.

• The abuse-report notes feature was abandoned. Its sibling tables were already dropped in 18.5 through 18.7, but this table was missed.
• The table also has a Cells compatibility problem: its unique index on (abuse_report_id, note_id) does not include the sharding key. Rather than fix the index on a dead table, we drop the table.
• Step 1 (dead code removal), merged in 19.4: !250375 (merged)
• Step 2 (removing the notes foreign key fk_a4bd02b7df): !251019 (merged)

Alongside the migrations this MR also:

• Moves the table dictionary file to db/docs/deleted_tables/, adding removed_by_url and removed_in_milestone.
• Removes the abuse_report_user_mentions entry from config/organizations/transfer_support.yml.
• Removes the removed_fks_map entry in spec/db/schema_spec.rb that step 2 added.

Do not merge yet

Commented out now that Remove foreign key between abuse_report_user_me... (!251019 - merged) has been merged and the post-deploy migration it introduced already ran in production.

Migrations

Three post-deployment migrations, run in this order. Each foreign key is removed in its own migration, as the migration style guide requires, so each lock has a small blast radius:

1. db/post_migrate/20260824055001_remove_foreign_key_between_abuse_report_user_mentions_and_abuse_reports.rb — removes fk_088018ecd8 to abuse_reports
2. db/post_migrate/20260824055002_remove_foreign_key_between_abuse_report_user_mentions_and_organizations.rb — removes fk_f4c2b15ef9 to organizations
3. db/post_migrate/20260824055003_drop_abuse_report_user_mentions_table.rb — drops the table

By the time the third migration runs, the table has no outgoing foreign keys left, so DROP TABLE only needs to lock the table itself.

Neither abuse_reports nor organizations appears in GitLab's list of large tables in rubocop/rubocop-migrations.yml; notes is the only one of the three that does. So these two locks are on comparatively quiet tables, unlike the one in step 2.

Data deletion

• Recovery: drop_table is not data-reversible. This migration's down method only recreates an empty table with its original indexes — it does not restore any rows. If rows needed to be recovered after an incident, the only path would be a database backup restore or point-in-time recovery.

  • Mitigating context: any surviving rows are already orphaned. This table could only ever have stored user mentions inside abuse-report notes, and those notes are gone — the underlying rows in the shared notes table were deleted in 17.2 (!155327 (merged)), and the dedicated abuse_report_notes table was dropped in 18.7 (!209042 (merged)). There is no longer anything for this data to attach to, even if it were recovered.

• Records affected: 0 (confirmed via console.postgres.ai)

  • nothing can write to this table anymore, since its only write path was abuse-report notes, and that feature was abandoned with its data already deleted. The database dictionary lists this table's size as small. All application code that referenced the table was already removed in 19.4 (!250375 (merged)).

• User experience impact: None. This feature never reached users — the first implementation shipped behind a feature flag that was never enabled, and the second implementation was removed before release.

  • There is no UI, API, or GraphQL surface that reads this table, and no model or factory references it (the dictionary already lists classes: []). There is nothing to communicate to users and no functional change from this migration.

References

Tracking issue: gitlab-com/gl-infra/tenant-scale/cells-infrastructure/team#781 (closed)

Incident follow-up, reintroduce the reverted changes as post-deployment migrations: gitlab-com/gl-infra/production-engineering#29559 (closed)

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.