Geo: Add missing FK constraint on geo_event_log.hashed_storage_attachments_event_id

In https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/7990 we added a foreign key constraint on geo_event_log.hashed_storage_attachments_event_id. But when deploying on GitLab.com we ran into geo_event_log rows that violated the constraint, described in https://gitlab.com/gitlab-org/gitlab-ee/issues/8302.

We created https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8257 to address that issue by removing the orphaned rows just before adding the FK.

But this is vulnerable to a race condition, from https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8257#note_115230385:

  • project with id 123 is migrated to hashed storage
  • for this project a geo_hashed_storage_attachments_events row is created with project_id = 123. This row has id 555
  • together with that, also a geo_event_log row is created, with hashed_storage_attachments_event_id = 555
  • now migration ee/db/migrate/20181017131623_add_missing_geo_even_log_indexes.rb is started
  • the code in #delete_missing_foreign_key_rows runs, but nothing is done to the row geo_hashed_storage_attachments_events with id 555
  • (here is the critical part) right before the FK constraint is added, project 123 is deleted
  • the foreign key constraint kicks in and deletes geo_hashed_storage_attachments_events with id 555
  • there is no FK constraint between geo_event_log and geo_hashed_storage_attachments_events (yet), so the geo_event_log row with hashed_storage_attachments_event_id = 555 remains
  • then the add_concurrent_foreign_key in the migration runs, and finds the violating row
  • 💥 💥 💥

So we decided to rollback the adding of the FK, and limit the migration to adding indexes.

This issue addresses proper adding the FK on geo_event_log.hashed_storage_attachments_event_id.