asset_proxy_whitelist prevents gitlab-backup restore on first attempt

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Hello,

I would like to report a reproducible issue affecting a normal GitLab Server restore process. Based on my understanding there's an inconsistency between the initial GitLab DB schema (after we run gitlab-rake db:migrate on a fresh install) and a restore process from the backup created by the gitlab-backup create BACKUP=testing. The problem itself is revolving around the asset_proxy_whitelist versus asset_proxy_allowlist naming dilemma.

In this scenario I have two systems, source (i.e., a backup source with all data, where we run gitlab-backup create BACKUP=testing) and target (i.e., a restore target with no data where we run gitlab-backup restore BACKUP=testing).

Here's what a source system has in the DB:

gitlabhq_production=> select asset_proxy_allowlist from application_settings;
ERROR:  column "asset_proxy_allowlist" does not exist
LINE 1: select asset_proxy_allowlist from application_settings;
               ^
gitlabhq_production=> select asset_proxy_whitelist from application_settings;
ERROR:  column "asset_proxy_whitelist" does not exist
LINE 1: select asset_proxy_whitelist from application_settings;
               ^

Neither asset_proxy_whitelist nor asset_proxy_allowlist are set.

Here's what a target system has in the DB:

gitlabhq_production=> select asset_proxy_allowlist from application_settings;
ERROR:  column "asset_proxy_allowlist" does not exist
LINE 1: select asset_proxy_allowlist from application_settings;
               ^
gitlabhq_production=> select asset_proxy_whitelist from application_settings;
 asset_proxy_whitelist
-----------------------

(1 row)

In this case we have only asset_proxy_whitelist set.

As you may see there's an inconsistency in the DB schema between these two systems. If I would run a normal restore process this inconsistency will end up as a failure followed by this error message:

Caused by:
PG::UndefinedColumn: ERROR:  column application_settings.asset_proxy_whitelist does not exist
LINE 1: ...lowlist", "application_settings"."kroki_formats", "applicati...
                                                             ^

However, if I would run the very same restore process again the problem is gone, and a restore process goes just fine without any issues. Here's what I see in the DB after that:

gitlabhq_production=> select asset_proxy_allowlist from application_settings;
ERROR:  column "asset_proxy_allowlist" does not exist
LINE 1: select asset_proxy_allowlist from application_settings;
               ^
gitlabhq_production=> select asset_proxy_whitelist from application_settings;
ERROR:  column "asset_proxy_whitelist" does not exist
LINE 1: select asset_proxy_whitelist from application_settings;
               ^

I could do the following to be able to reproduce this behaviour:

# gitlab db:reset
# gitlab db:migrate
# gitlab-backup restore BACKUP=testing

It also works if I'd drop the DB beforehand, and create a new DB with no data in it.

To sum up, to be able to restore from a backup file I should drop the DB first, or re-run the restore script two times.

Based on my quick analysis, on a fresh install a column being created because of this line here:

Edited by 🤖 GitLab Bot 🤖