Phase 2a - Inject record_store into LFK services

Leonardo da Rosarequested to merge
597949/phase-2a-changes into master

What does this MR do and why?

Make LFKs compatible with cells.

This MR injects a record_store: keyword argument into the two LFK cleanup services so they no longer hardcode LooseForeignKeys::DeletedRecord.

The default value is LooseForeignKeys::DeletedRecord, so production behavior is unchanged by this MR alone. The new seam lets Phase 2 (b) swap in the Gitlab::LooseForeignKeys::DeletedRecordStore facade without touching service internals.

Phase MR
1 - Foundation !233234 (merged)
2 (a) - Inject record_store into LFK services This MR
2 (b) - DeletedRecordStore facade + workers + feature flag -
3 - Trigger function update + first table rollout -
4 - Gradual trigger rollout -
5 - Cleanup -

About the changes

  1. LooseForeignKeys::BatchCleanerService now accepts a record_store: keyword argument (default LooseForeignKeys::DeletedRecord). The four hardcoded call sites are routed through @record_store:
    • mark_records_processed (in #execute)
    • reschedule and increment_attempts (in #handle_over_limit)
    • db_config_name (now resolves via record_store.connection.pool.db_config.name instead of the hardcoded class)
  2. LooseForeignKeys::ProcessDeletedRecordsService accepts the same keyword argument, swaps its load_batch_for_table call to go through @record_store, and forwards record_store to BatchCleanerService.new.
  3. Specs cover the default value, the forwarded value, and the db_config_name resolution path.

Related #597949

Merge request reports