### Problem to solve With object storage replication and a `bucket_prefix`, the `blob_path` a Geo secondary stores on a registry starts with the prefix, but `Upload#path`, the LFS oid and `object_storage_key` never include it. `blob_location_in_use?` then never matches for uploads, LFS objects, Helm metadata caches and NuGet symbols, so the stored-location fallback in `Geo::DestroyWorker` can delete an object that a newer record reuses. ### Proposal `Geo::BlobReplicatorStrategy#registry_location_params` should treat the stored location as in use when `blob_location_in_use?` matches either the stored path or the stored path without the uploader's `object_store_options.bucket_prefix`. Both checks are needed because a local path can start with the prefix by chance. The location that `registry_location_params` returns keeps the prefix, because the removal service needs it to find the object. Specs with a bucket prefix cover an upload replicator and an object storage key type. This must land before `geo_blob_removal_uses_registry_location` is enabled by default (https://gitlab.com/gitlab-org/gitlab/-/work_items/635220). Related to https://gitlab.com/gitlab-org/gitlab/-/merge_requests/263964 ### Background - On a Geo secondary, each blob registry row stores `blob_path`, the file's path relative to its uploader root (or its object storage key). Upload registries also store `uploader_class`. `Geo::BlobDownloadService#record_blob_location` writes both from `replicator.deleted_params`, which uses `carrierwave_uploader.relative_path`. - When the record is gone on the primary and the delete event has no path, `Geo::BlobReplicatorStrategy#registry_location_params` returns the stored location, and `Geo::FileRegistryRemovalService` deletes the file. Before that, `blob_location_in_use?` checks whether a newer record reuses the same path, so its file is never deleted. - For files on object storage, `ObjectStorage::Concern#store_path` adds the bucket prefix, so the stored path is `<bucket_prefix>/<key>`. The values that the `blob_location_in_use?` overrides compare against never include the prefix: `Upload#path` (`Geo::Concerns::UploadReplicatorBehavior`), the LFS oid (`Geo::LfsObjectReplicator`), and `object_storage_key` (`Geo::PackagesHelmMetadataCacheReplicator`, `Geo::PackagesNugetSymbolReplicator`). The check therefore never matches. `Geo::TerraformStateVersionReplicator` only reads the last two path segments, so it is not affected. ### Implementation plan The only code file that changes is `ee/app/models/concerns/geo/blob_replicator_strategy.rb`. - `registry_location_params` calls a new private method, `stored_location_in_use?(blob_path, uploader_class)`, in place of `blob_location_in_use?`. The hash it returns keeps the stored path unchanged, because the removal service needs the prefixed key to find the object. - `stored_location_in_use?` returns true when `blob_location_in_use?` matches either the stored path or the stored path without the `"#{bucket_prefix}/"` prefix. A local path can start with the prefix by chance: with `remote_directory: gitlab/uploads` the prefix is `uploads`, and a local avatar path is `uploads/-/system/...`. A wrong "in use" result only leaves an orphaned file, but a wrong "not in use" result deletes a file that a live record uses. ```ruby # Object storage keys start with the bucket prefix, but the columns the in-use checks match never include it. # A local path can start with the prefix too, so a match with or without it counts. def stored_location_in_use?(blob_path, uploader_class) bucket_prefix = uploader_class.constantize.object_store_options.bucket_prefix paths = [blob_path] paths << blob_path.delete_prefix("#{bucket_prefix}/") if bucket_prefix.present? paths.uniq.any? { |path| blob_location_in_use?(path, uploader_class) } end ``` Constraints: - The existing `ObjectStorage::Concern.without_bucket_prefix` helper does not fit: for a path outside the prefix, `Pathname#relative_path_from` returns `../../...`. - The default `blob_location_in_use?` and its replicator overrides stay unchanged. - The `constantize` call needs no rescue, because `removed_blob_path` constantizes the same class right afterwards. #### Specs 1. `ee/spec/support/shared_examples/models/concerns/blob_replicator_reusable_blob_path_shared_examples.rb` gets a `describe '#replicate_destroy with a bucket prefix'` block. The LFS, Helm metadata cache, NuGet symbol and Terraform replicator specs all use this shared example. The block's setup does three things: - It stubs the prefix the same way `spec/uploaders/object_storage_spec.rb` does: `allow(uploader_class.constantize.object_store_options).to receive(:bucket_prefix).and_return('my/prefix')`. - It creates the registry with `blob_path: File.join('my/prefix', blob_path)`. - It deletes `model_record`. The block has two examples: - When `record_reusing_path` exists, `Geo::FileRegistryRemovalService.new` receives `(replicable_name, model_record_id, nil, nil)`. - When it does not, the service receives `File.join(uploader_class.constantize.root, 'my/prefix', blob_path)` and `uploader_class`. `create_registry_with_location` and `expect_removal_service_with` in `blob_replicator_removes_blob_using_stored_location_shared_examples.rb` show the registry and service setup to copy. 2. `ee/spec/replicators/geo/user_upload_replicator_spec.rb` gets the same two examples. User avatars use `AvatarUploader`, which can reuse a path. The reusing record is `create(:upload, model: model_record.model, path: model_record.path)`, and the registry stores `uploader_class: model_record.uploader`. A third example covers a local path that starts with the prefix: it sets the prefix to `uploads`, stores `model_record.path` unchanged (a local path starting with `uploads/`), and creates the reusing record. The service must still receive `nil, nil`. #### Verification - The examples that expect `nil, nil` fail on master for LFS, Helm, NuGet and user uploads; you can confirm this by stashing the code change. Terraform passes either way. The third user-upload example fails if only the shorter path is checked. - `bin/rspec ee/spec/replicators/geo/ ee/spec/workers/geo/destroy_worker_spec.rb` passes. Every blob replicator spec runs the stored-location shared examples, so the change is covered across all types. - `bundle exec rubocop` passes on the changed files.