<!--- Please read this! Before opening a new issue, make sure to search for keywords in the issues filtered by the "regression" or "type::bug" label: - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug and verify the issue you're about to submit isn't a duplicate. ---> ### Summary <!-- Summarize the bug encountered concisely. --> When there is a severe configuration problem, the secondary's container repository sync job will mark the registry record as `synced` and exit successfully. Even though no replication will occur. ### Steps to reproduce <!-- Describe how one can reproduce the issue - this is very important. Please use an ordered list. --> For example, when the secondary's configs contain an incorrect primary registry API URL: `gitlab_rails['geo_registry_replication_primary_api_url'] = 'somethingwrong'`. Or for example, when the secondary's configs contain an incorrect (local) registry API URL: `gitlab_rails['registry_api_url'] = "somethingwrong"`. Or for example, when the secondary's configs contain an incorrect token issuer: `gitlab_rails['registry_issuer'] = "somethingwrong"`. Then, when creating a new container repository, or when adding images or tags to an existing container repository, the changes do not replicate to the secondary's container registry. Yet, the replication progress bar appears to be `synced`. ### What is the current *bug* behavior? <!-- Describe what actually happens. --> Geo replication progress of container registry does not have failures when it is not working. ### What is the expected *correct* behavior? <!-- Describe what you should see instead. --> Geo replication progress of container registry should have failures when it is not working. ### Relevant logs and/or screenshots <!-- Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's tough to read otherwise. --> ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem. --> > it returns `[]` as the list of tags when it could have told me there was an error talking to registry instead