Remove abuse report notes and user mentions code

What does this MR do and why?

Removes the dead abuse-report notes and user mentions code. No database changes — this is step 1 of 3 re-introducing the removal that was reverted after INC-13070.

Why this code is dead

Notes on abuse reports were attempted twice and abandoned both times:

  1. In the shared notes table, behind the abuse_report_notes feature flag, which was never enabled. Those rows were deleted in 17.2 because notes could not be sharded by namespace while they existed: !155327 (merged)
  2. In a dedicated abuse_report_notes table, dropped in 18.7 under a breaking-change exception — "never released to any customers or instances, so they represent dead code": !209042 (merged) and gitlab-com/Product#14362 (closed)

The sibling tables went with it — abuse_report_assignees in 18.5, abuse_report_labels in 18.6 — but abuse_report_user_mentions and the model wiring that fed it were missed.

Nothing can reach that wiring today. An abuse-report note cannot be created at all: Note requires a namespace for non-project noteables (app/models/note.rb), and does_not_exceed_notes_limit? calls noteable.notes, which AbuseReport does not define.

Why this is code-only

A previous attempt combined this code removal with three foreign key removals and the table drop in one merge request, with the foreign key removals as regular migrations. On production-canary, removing the foreign key to notes could not acquire ACCESS EXCLUSIVE on that table, exhausted its lock retries, and blocked auto-deploy close to the monthly release window (INC-13070). It was reverted: !249546 (merged)

Per avoiding downtime in migrations, dropping a table is a multi-release process: remove application code in one release, then remove the foreign keys and drop the table in separate post-deployment migrations in the next. This merge request is that first release. The schema changes follow:

  • Next: remove the notes foreign key, alone, in its own post-deployment migration.
  • After that is verified applied on GitLab.com: remove the abuse_reports and organizations foreign keys and drop the table.

What this removes

The mention model and its association, the orphaned AntiAbuse::Reports::IndividualNoteDiscussion, the Mentionable and Noteable wiring on AbuseReport, AbuseReport from Noteable's replyable and resolvable type lists, Note#for_abuse_report? and its four callers, the matching UrlBuilder branch, and the factory and specs.

AbuseReport#project goes too — it existed only so the createNote mutation could call noteable.project. The one other caller, CacheMarkdownField, guards it with respond_to?, so returning nil and not responding at all are equivalent there.

What is deliberately left in place

The table still exists until the follow-up merge requests, so db/docs/abuse_report_user_mentions.yml and its config/organizations/transfer_support.yml entry both stay. The dictionary's classes: key is emptied because the class it named is gone; the dictionary file itself moves to db/docs/deleted_tables/ when the table is dropped.

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 Eugie Limpin

Merge request reports

Loading
Loading