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
ArchiveAuthenticationEventsBBM to hard delete records instead of archive them - This way the job no longer references the
authentication_event_archived_recordstable, 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
- #562154
- Old issue implementing archival: #545007 (closed)
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