### Summary If a password is due for reencryption, if the first git operation is being executed in the secondary, the password update will be attempted on the read-only database replica. The git operation also fails in this scenario. Trying the same operation on the primary site successfully updates the password. The git operation also works properly on the secondary after the password is properly updated. ### Steps to reproduce I bumped into this issue when switching between 2 stable branches, specifically from `17-11-stable-ee` to `18-0-stable-ee` . After switching I started firing GET requests to `info/refs/?service=git-upload-pack` and was getting HTTP 500 ### What is the current _bug_ behavior? A git operation over HTTP will return 500 due to attempts to reencrypt the user's password, on the secondary site's database. ### What is the expected _correct_ behavior? The secondary's database is read-only, reencryption of passwords should be skipped on secondary sites until the primary site is reached. ### Relevant logs and/or screenshots ``` 2025-05-16_23:59:28.05522 postgresql : 2025-05-16 16:59:28.055 PDT [13455] ERROR: cannot execute UPDATE in a read-only transaction 2025-05-16_23:59:28.05525 postgresql : 2025-05-16 16:59:28.055 PDT [13455] STATEMENT: UPDATE "users" SET "encrypted_password" = '$2a$13$nIYfkGE1TvekQH/ikG9A2uKJWKh1UcLL0qqwNm6TRSpavCFzXvVZu' WHERE "users"."id" = 70 /*application:web,correlation_id:01JVDRKQ93YZHBZDDPS8YXQNZ3,endpoint_id:Repositories::GitHttpController#info_refs,db_config_database:gitlabhq_development,db_config_name:main,line:/app/models/concerns/encrypted_user_password.rb:97:in `migrate_password!'*/ ``` ### Possible fixes The operation needs to be skipped on secondary sites. As a workaround, doing the same operation on the primary first, the password will be updated, then the secondary can be used again normally. ## Implementation Plan Prevent password re-encryption from attempting database writes on Geo secondary sites during authentication. ### Background `EncryptedUserPassword#valid_password?` verifies the supplied password and then calls `migrate_password!` when the stored password hash should be upgraded to the current encryption format or parameters. On a Geo secondary site, this can happen during a Git HTTP authentication request. `migrate_password!` currently calls `update_column(:encrypted_password, ...)`, which attempts to write to the read-only secondary database and causes the Git operation to fail with HTTP 500. ### Proposed change 1. Update `EncryptedUserPassword#migrate_password!` in `app/models/concerns/encrypted_user_password.rb`. 2. After confirming the password is valid, skip the password migration when the current node is a Geo secondary or organization migration target. Suggested guard: `return true if ::Gitlab::Geo.secondary_or_org_migration_target?` Place this after: `return true if migrated_password?` This preserves the current behavior when no migration is needed and avoids writes only when a migration would otherwise be attempted. 3. Keep the method return value truthy so authentication succeeds even though the password hash was not upgraded on the secondary. 4. Do not attempt to enqueue background work from the secondary. The password should be upgraded naturally the next time the user authenticates through the primary site, where writes are allowed. ### Test coverage Add specs in `spec/models/concerns/encrypted_user_password_spec.rb`. 1. Add a context for a Geo secondary site where the stored password requires migration. 2. Stub Geo secondary behavior, for example: `allow(::Gitlab::Geo).to receive(:secondary_or_org_migration_target?).and_return(true)` 3. Verify that `valid_password?` still returns `true`. 4. Verify that `encrypted_password` is not changed. 5. Verify that no database write is attempted for the password migration, for example by expecting the user not to receive `update_column`: `expect(user).not_to receive(:update_column)` 6. Keep or add coverage confirming that on non-secondary sites the password is still migrated as before. ### Acceptance criteria - Git HTTP authentication on a Geo secondary succeeds when the user's password hash is due for migration. - The secondary does not attempt to update `users.encrypted_password`. - The password hash is still migrated when the same user authenticates on the primary. - Existing password migration behavior outside Geo secondary sites is unchanged. ### Implementation note `EncryptedUserPassword` lives in `app/models/concerns/encrypted_user_password.rb`, so the implementation should use a Geo predicate that is safe in both CE and EE contexts. If `::Gitlab::Geo.secondary_or_org_migration_target?` is not available in CE, use the existing CE-safe Geo predicate pattern used elsewhere in shared code. <!--If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"`-->