Upgrade to 9.1.4 fails on sidekiq

Summary

While there is no announcement yet, there is a 9.1.4 omnibus package for gitlab available for Gitlab EE. I tried updating from the latest 9.1.3 EE and it went wrong. The upgrade fails on the Sidekiq step.

Steps to reproduce

Upgrade from 9.1.3 EE to 9.1.4 using omnibus.

What is the current bug behavior?

Sidekiq/Redis failed upgrading. Eventually Gitlab does start and shows the 9.1.4 version on the admin page.

What is the expected correct behavior?

Usual upgrade

Relevant logs and/or screenshots

Upgrade command-line output:

upgrade.log

Output of checks

Results of GitLab environment info

(After the upgrade)

System information
System:		Debian 8.8
Proxy:		no
Current User:	git
Using RVM:	no
Ruby Version:	2.3.3p222
Gem Version:	2.6.6
Bundler Version:1.13.7
Rake Version:	10.5.0
Redis Version:	3.2.5
Git Version:	2.11.1
Sidekiq Version:4.2.7
GitLab information
Version:	9.1.4-ee
Revision:	cd361c2
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	postgresql
DB Version:	9.6.1
URL:		https://*************
HTTP Clone URL:	https://*************/some-group/some-project.git
SSH Clone URL:	git@*************:some-group/some-project.git
Elasticsearch:	yes
Geo:		no
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers: google_oauth2, bitbucket
GitLab Shell
Version:	5.0.2
Repository storage paths:

• default: /var/opt/gitlab/git-data/repositories Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks Git: /opt/gitlab/embedded/bin/git You have new mail in /var/mail/root

Results of GitLab application Check

Checking GitLab Shell ...
GitLab Shell version >= 5.0.2 ? ... OK (5.0.2)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ...
4/2 ... ok
4/3 ... ok
4/5 ... ok
4/7 ... ok
4/8 ... ok
4/9 ... ok
4/10 ... ok
4/11 ... ok
4/12 ... ok
4/13 ... ok
4/14 ... ok
4/15 ... ok
4/16 ... ok
4/17 ... ok
4/18 ... ok
4/19 ... ok
4/20 ... ok
4/21 ... ok
4/22 ... ok
4/23 ... ok
4/24 ... ok
4/25 ... ok
4/26 ... ok
4/28 ... ok
4/29 ... ok
4/30 ... ok
4/32 ... ok
4/33 ... repository is empty
4/35 ... ok
4/36 ... ok
4/38 ... ok
16/39 ... ok
4/40 ... ok
17/41 ... ok
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: OK
Send ping to redis server: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Sidekiq ...
Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking Reply by email ...
Reply by email is disabled in config/gitlab.yml
Checking Reply by email ... Finished
Checking LDAP ...
LDAP is disabled in config/gitlab.yml
Checking LDAP ... Finished
Checking GitLab ...
Git configured with autocrlf=input? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory setup correctly? ... yes
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: ...
4/2 ... yes
4/3 ... yes
4/5 ... yes
4/7 ... yes
4/8 ... yes
4/9 ... yes
4/10 ... yes
4/11 ... yes
4/12 ... yes
4/13 ... yes
4/14 ... yes
4/15 ... yes
4/16 ... yes
4/17 ... yes
4/18 ... yes
4/19 ... yes
4/20 ... yes
4/21 ... yes
4/22 ... yes
4/23 ... yes
4/24 ... yes
4/25 ... yes
4/26 ... yes
4/28 ... yes
4/29 ... yes
4/30 ... yes
4/32 ... yes
4/33 ... yes
4/35 ... yes
4/36 ... yes
4/38 ... yes
16/39 ... yes
4/40 ... yes
17/41 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.1.0 ? ... yes (2.3.3)
Your git bin path is "/opt/gitlab/embedded/bin/git"
Git version >= 2.7.3 ? ... yes (2.11.1)
Active users: 13
Elasticsearch version 5.1.x? ... no, you have 5.2.2
Checking GitLab ... Finished

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)