Geo primary performance can be degraded by a non-responsive geo-secondary, causing 500 errors (failure of HA configuration)
Summary
The Drupal project has a self-hosted GitLab Omnibus instance, with OSS/ultimate license, at git.drupalcode.org.
When performing last week's security update, our geo secondary took notably longer to upgrade than our geo primary.
However, our Geo primary started giving 500 errors, apparently because the Git Clone widget is trying to call back to the secondary in a geo configuration.
This seems like an unintended behavior, having the primary instance dependent on the availability of the secondary seems like a mistaken dependency that undermines high availability principles.
Steps to reproduce
Within a Geo configuration, in some way degrade the secondary, taking it offline, or run a pending update, etc.
During this time, try to load GitLab project pages. You should see 500 errors.
What is the current bug behavior?
500 errors on the primary caused by lack of availability of the secondary.
What is the expected correct behavior?
The primary should not depend on the secondary.
Relevant logs and/or screenshots
It appears that: ee/app/helpers/ee/gitlab_routing_helper.rb:29:in'geo_proxied_ssh_url_to_repo' is creating some kind of dependency on the secondary for the primary to function.