Skip to content

Pushes to forks don't enforce LFS integrity if the LFS object exists in the canonical project

The Gitlab::Checks::LfsIntegrety#objects_missing? still uses Project#all_lfs_objects which includes the lfs objects from the canonical. So the push isn't rejected because of the missing LFS objects while it should have been.

Summary

This is a follow-up for: #20042 (closed)

I've been testing the changes made in !22418 (merged).

It does what the description says, but I feel we've missed something

Steps to reproduce

  1. Create a source project with LFS
  2. Fork it
  3. Change/add a LFS object to the source project
  4. Update the forked project the HEAD of the source project

What is the current bug behavior?

No LfsObjectsProject is created for the forked project.

LfsObjectsProject for the source project (project_id = 11):

LfsObject.joins(:lfs_objects_projects).where(lfs_objects_projects: { project_id: 11 })
  LfsObject Load (0.8ms)  SELECT "lfs_objects".* FROM "lfs_objects" INNER JOIN "lfs_objects_projects" ON "lfs_objects_projects"."lfs_object_id" = "lfs_objects"."id" WHERE "lfs_objects_projects"."project_id" = 11 /*application:console,line:/ee/lib/gitlab/database/load_balancing/connection_proxy.rb:63:in `block in read_using_load_balancer'*/
=> [#<LfsObject:0x00005648fa95e518
  id: 20,
  oid: "78e953c05cfd141abd482193c7c4b931b3ff263bfd4ebf09cfea8bf45a5b2113",
  size: 1171829,
  created_at: Wed, 19 Feb 2020 09:19:20 UTC +00:00,
  updated_at: Wed, 19 Feb 2020 09:19:20 UTC +00:00,
  file: "53c05cfd141abd482193c7c4b931b3ff263bfd4ebf09cfea8bf45a5b2113",
  file_store: 1>,
 #<LfsObject:0x00005648fa95e450
  id: 21,
  oid: "32ec69afd4dbce810667032eced6398b8c59e3bbbce75a53160d00ca0658f82e",
  size: 1179888,
  created_at: Wed, 19 Feb 2020 09:29:13 UTC +00:00,
  updated_at: Wed, 19 Feb 2020 09:29:13 UTC +00:00,
  file: "69afd4dbce810667032eced6398b8c59e3bbbce75a53160d00ca0658f82e",
  file_store: 1>]

LfsObjectsProject for the fork project (project_id = 12):

LfsObject.joins(:lfs_objects_projects).where(lfs_objects_projects: { project_id: 12 })
  LfsObject Load (1.3ms)  SELECT "lfs_objects".* FROM "lfs_objects" INNER JOIN "lfs_objects_projects" ON "lfs_objects_projects"."lfs_object_id" = "lfs_objects"."id" WHERE "lfs_objects_projects"."project_id" = 12 /*application:console,line:/ee/lib/gitlab/database/load_balancing/connection_proxy.rb:63:in `block in read_using_load_balancer'*/
=> [#<LfsObject:0x0000564900ddc0a8
  id: 20,
  oid: "78e953c05cfd141abd482193c7c4b931b3ff263bfd4ebf09cfea8bf45a5b2113",
  size: 1171829,
  created_at: Wed, 19 Feb 2020 09:19:20 UTC +00:00,
  updated_at: Wed, 19 Feb 2020 09:19:20 UTC +00:00,
  file: "53c05cfd141abd482193c7c4b931b3ff263bfd4ebf09cfea8bf45a5b2113",
  file_store: 1>]

What is the expected correct behavior?

When the new HEAD is pushed to the forked project, a LfsObjectsProject is created for the forked project.

Possible fixes

diff --git a/lib/gitlab/checks/lfs_integrity.rb b/lib/gitlab/checks/lfs_integrity.rb
index 1652d5a30a4..b908f36f81d 100644
--- a/lib/gitlab/checks/lfs_integrity.rb
+++ b/lib/gitlab/checks/lfs_integrity.rb
@@ -18,7 +18,7 @@ module Gitlab
 
         return false unless new_lfs_pointers.present?
 
-        existing_count = @project.all_lfs_objects
+        existing_count = @project.lfs_objects
                                  .where(oid: new_lfs_pointers.map(&:lfs_oid))
                                  .count
 
Edited by Bob Van Landuyt