Draft: Change deletion strategy from soft deletion to hard deletion in ArchiveAuthenticationEvents BBM

What does this MR do and why?

Previous context

  • In !202447 (merged) we introduced a BBM to enforce a retention policy on old rows in authentication_events
  • The BBM stored old rows in an archival table for backup, then deleted the old rows from production
  • The archival table was just for risk mitigation
  • We've confirmed there were no negative impacts from deleting authentication_events, so we can start hard deleting them now

This MR

  • This MR changes the ArchiveAuthenticationEvents BBM to hard delete records instead of archive them
  • This way the job no longer references the authentication_event_archived_records table, paving the way for us to delete the table
  • The BBM has already been run and finalized on .com, and was never enqueued for self-hosted, so the job will probably never be enqueued again -- this is just code maintenance.

References

Screenshots or screen recordings

How to set up and validate locally

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.

Related to #562154

Merge request reports

Loading