Background Jobs for Secret Rotation Reminders
Summary
This issue focuses on implementing background jobs to automatically send email reminders to project owners when their secrets are approaching rotation dates.
Proposal
Based on team discussions and architecture evaluation (including the comparison between single-table vs. two-table partitioned approaches), we will implement a background job system using the single-table approach with the existing rotation_infos table. This includes:
- Creating a background job to scan for secrets requiring rotation reminders
- Implementing email notification logic using GitLab's existing email system
- Establishing reminder scheduling logic based on rotation intervals
- Cleaning up orphaned rotation info records
Technical Architecture Decision
After discussion, the team has decided to proceed with the single-table approach based on:
- Scale Analysis: Considering this is Ultimate license only feature, the amount of secrets is not a big concern
- Update Frequency: Weekly/monthly rotations with distributed scheduling won't create significant PostgreSQL performance issues
- Precedent: GitLab already uses similar indexed-update patterns (e.g., user status clearing)
- Simplicity: Lower complexity for initial implementation, with clear migration path if needed
Decision Reference: Internal discussion notes #555421 (comment 2727477710)
Reminder Scheduling Logic
Based on team discussions in this thread:
-
Timing: Always round up to next day at 00:00:00 UTC
- Example: Secret updated Sept 3rd 10pm + 7 days interval = reminder Sept 11th 00:00
- Recipients: Email notifications sent only to project owners
- Frequency: Background job runs every 1 minute with 30-second runtime limit
Database Schema
Uses the existing rotation_infos table structure with:
-
next_reminder_at(datetime, indexed) - when to send the next reminder -
last_reminder_sent_at(datetime) - tracks when reminder was last sent -
rotation_interval_days(integer) - user-configured rotation interval
Performance Note: The indexed next_reminder_at column will be frequently updated, but analysis shows this is acceptable given the expected scale and update frequency patterns.