git push fails on large lfs files where the push take a long time

Summary

git push fails if a local repository contains one or more lfs files which take a long time to upload

Steps to reproduce

Create a project which contains one or more large files in lfs, where the time taken to upload them would be longer than the authentication timeout, currently 18000 seconds (30 minutes) in:

https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/lfs_token.rb

Execute a git push to a GitLab server.

Example Project

I am storing very large files on a locally installed server, which is fire-walled off from external access.

An example on GitLab wouldn't help as you'd need a local repo with very large files in lfs to reproduce the problem.

What is the current bug behavior?

After a long time the push fails with the following (GitLab 11.7.4 CE):

[gaddis@jaga cirrhosis_baseline_calling]$ git push
Host key fingerprint is 3a:49:96:81:be:b0:9c:61:23:a9:3c:66:7d:a2:ff:c7
+--[ RSA 2048]----+
|                 |
|     .           |
|    . .          |
| . .   o         |
|o = . + S        |
|o+.* + o         |
|.=+o..=          |
|o o o  E         |
| ......          |
+-----------------+

Locking support detected on remote "origin". Consider enabling it with:
  $ git config lfs.https://stophcvdatastore.ndm.ox.ac.uk/data_analysis/host_genotyping/cirrhosis_cohort/cirrhosis_baseline/cirrhosis_baseline_calling.git/info/lfs.locksverify true
batch response: Authentication required: Authorization error: https://stophcvdatastore.ndm.ox.ac.uk/data_analysis/host_genotyping/cirrhosis_cohort/cirrhosis_baseline/cirrhosis_baseline_calling.git/info/lfs/objects/batch
Check that you have proper access to the repository
error: failed to push some refs to 'git@stophcvdatastore.ndm.ox.ac.uk:data_analysis/host_genotyping/cirrhosis_cohort/cirrhosis_baseline/cirrhosis_baseline_calling.git'
[gaddis@jaga cirrhosis_baseline_calling]$ 

If all of the files in lfs take less than the timeout to upload, simply repeating the push as many times as required is enough to upload all the files eventually.

If any one file, on its own, takes longer than the timeout to upload, it is not possible to complete the upload.

What is the expected correct behavior?

The push succeeds (but takes a very long time).

Relevant logs and/or screenshots

In a release prior to 11.5.4 it was possible to run a parallel job to renew the authorisation by calling git-lfs-authenticate at a period less than the timeout value.

Here are the responses from two calls to git-lfs-authenticate spaced 2 minutes apart, prior to the installation of 11.5.4.

{"header":{"Authorization":"Basic R3JhaGFtSmFtZXNBZGRpczpEUFI2aW9HX1MzQzRDUHh3eGF5R3I0dVJZcXVHMkpzUGhvbTZZaGZtMS1ieDcxRlNzdw=="},"href":"https://stophcvdatastore.ndm.ox.ac.uk/data_retention/host_genotyping/p150202/p150202_p05.git/info/lfs/"}

{"header":{"Authorization":"Basic R3JhaGFtSmFtZXNBZGRpczpEUFI2aW9HX1MzQzRDUHh3eGF5R3I0dVJZcXVHMkpzUGhvbTZZaGZtMS1ieDcxRlNzdw=="},"href":"https://stophcvdatastore.ndm.ox.ac.uk/data_retention/host_genotyping/p150202/p150202_p05.git/info/lfs/"}

Here are the responses with 11.5.4 installed, which show that GitLab is now responding with different authorisation keys, the same behaviour exists on 11.7.4:

{"header":{"Authorization":"Basic R3JhaGFtSmFtZXNBZGRpczpleUowZVhBaU9pSktWMVFpTENKaGJHY2lPaUpJVXpJMU5pSjkuZXlKa1lYUmhJanA3SW1GamRHOXlJam9pUjNKaGFHRnRTbUZ0WlhOQlpHUnBjeUo5TENKcWRHa2lPaUkzWlRNeVltUmtOQzB4WXprM0xUUTNZVFF0WW1NeE55MDFNR0U1TkRsaE1qa3hPREVpTENKcFlYUWlPakUxTkRjMk16azROaklzSW01aVppSTZNVFUwTnpZek9UZzFOeXdpWlhod0lqb3hOVFEzTmpReE5qWXlmUS5zZEV3amtxVF9tamxDQnlWclJJcVRhdGltck1rX0ZxNXJiX1ktZmktNktn"},"href":"https://stophcvdatastore.ndm.ox.ac.uk/data_retention/host_genotyping/p150202/p150202_p06.git/info/lfs/"}

{"header":{"Authorization":"Basic R3JhaGFtSmFtZXNBZGRpczpleUowZVhBaU9pSktWMVFpTENKaGJHY2lPaUpJVXpJMU5pSjkuZXlKa1lYUmhJanA3SW1GamRHOXlJam9pUjNKaGFHRnRTbUZ0WlhOQlpHUnBjeUo5TENKcWRHa2lPaUptTW1Jd1lXUmpPUzA1TTJRMkxUUm1ZbUl0T0RCaE15MWpPREF5Wm1SaU1EY3dNVGdpTENKcFlYUWlPakUxTkRjMk16azVPRFVzSW01aVppSTZNVFUwTnpZek9UazRNQ3dpWlhod0lqb3hOVFEzTmpReE56ZzFmUS55aWVtYV9CeTRWVWZPUmE0S1F5bnBFUjhzOE9zdktvMm9jMUZrTF94TmJv"},"href":"https://stophcvdatastore.ndm.ox.ac.uk/data_retention/host_genotyping/p150202/p150202_p06.git/info/lfs/"}

Output of checks

I have not tried this on GitLab.com.

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:env:info)
System information
System:		Ubuntu 18.04
Current User:	git
Using RVM:	no
Ruby Version:	2.5.3p105
Gem Version:	2.7.6
Bundler Version:1.16.6
Rake Version:	12.3.2
Redis Version:	3.2.12
Git Version:	2.18.1
Sidekiq Version:5.2.3
Go Version:	unknown
GitLab information
Version:	11.7.4
Revision:	1b59453d73d
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	postgresql
URL:		https://stophcvdatastore.ndm.ox.ac.uk
HTTP Clone URL:	https://stophcvdatastore.ndm.ox.ac.uk/some-group/some-project.git
SSH Clone URL:	git@stophcvdatastore.ndm.ox.ac.uk:some-group/some-project.git
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers:
GitLab Shell
Version:	8.4.4
Repository storage paths:

• default: /var/opt/gitlab/git-data/repositories Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks Git: /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
gaddis@stophcvdatastore:~$ sudo gitlab-rake gitlab:check SANITIZE=true
Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 8.4.4 ? ... OK (8.4.4)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Gitaly ...
Gitaly: ... default ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking Incoming Email ...
Incoming Email: ... Reply by email is disabled in config/gitlab.yml
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... LDAP is disabled in config/gitlab.yml
Checking LDAP ... Finished
Checking GitLab App ...
Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet)
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
5/1 ... yes
5/2 ... yes
5/3 ... yes
5/4 ... yes
5/6 ... yes
5/7 ... yes
5/8 ... yes
6/9 ... yes
6/10 ... yes
6/11 ... yes
6/12 ... yes
6/13 ... yes
7/14 ... yes
7/15 ... yes
7/16 ... yes
7/17 ... yes
7/18 ... yes
7/19 ... yes
8/20 ... yes
8/21 ... yes
8/22 ... yes
9/23 ... yes
9/24 ... yes
9/25 ... yes
10/26 ... yes
10/27 ... yes
10/28 ... yes
10/29 ... yes
10/30 ... yes
11/32 ... yes
6/33 ... yes
11/34 ... yes
11/35 ... yes
11/36 ... yes
11/37 ... yes
11/38 ... yes
11/39 ... yes
11/40 ... yes
11/41 ... yes
11/42 ... yes
11/43 ... yes
11/44 ... yes
9/45 ... yes
9/46 ... yes
12/47 ... yes
12/48 ... yes
14/49 ... yes
14/50 ... yes
18/51 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.5.3)
Git version >= 2.18.0 ? ... yes (2.18.1)
Git user has default SSH configuration? ... yes
Active users: ... 2
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished
gaddis@stophcvdatastore:~$

Possible fixes

An mr https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6551 seemed to have introduced the correct behaviour back in Sep 2016.

I'm assuming this was broken by the changes to lib/gitlab/lfs_token.rb in this recent change:

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23861

Correcting this would allow the workaround to work again.

A complete fix would require the introduction of the expire_in, or expire_at, properties, so that git-lfs would request new authorisation prior to the expiry time.

See: https://github.com/git-lfs/git-lfs/blob/master/docs/api/authentication.md for more details.