<!--- 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 On a Geo secondary, GraphQL requests via `/api/v4/geo/node_proxy/:id/graphql` fail with `PG::ReadOnlySqlTransaction: ERROR: cannot execute UPDATE in a read-only transaction`. The sessionless auth flow for this endpoint triggers Devise Lockable's `reset_failed_attempts!`, which attempts a write against the secondary's read-only database whenever the user's `failed_attempts` counter is nonzero. Because the write never succeeds, the counter is never reset, so the request fails on every call. ### Steps to reproduce 1. Have a `failed_attempts > 0` on a user (e.g. from an unrelated failed login/auth attempt). 2. On a Geo secondary, send a request to `/api/v4/geo/node_proxy/:id/graphql` authenticated as that user (this is what the Admin Area → Geo Sites page uses to poll replication status). 3. Observe the request fails with `PG::ReadOnlySqlTransaction`, and the failure repeats on every subsequent call since `failed_attempts` is never cleared. Note: normal UI sign-in is unaffected, since it authenticates once and reuses a session cookie rather than re-running sessionless auth on each request. ### What is the current *bug* behavior? Sessionless authentication on the Geo node proxy endpoint runs Devise's Lockable `after_authentication` hook (`reset_failed_attempts!`), which issues a real `UPDATE users SET failed_attempts = 0` against the local database. On a Geo secondary this database is a read-only streaming replica, so the write fails and raises an unhandled `ActiveRecord::StatementInvalid`. ### What is the expected *correct* behavior? Sessionless auth on Geo secondary/read-only routes should not attempt to write `failed_attempts` (or any other Lockable state) to the local database. Either skip the Lockable reset hook on read-only connections/secondaries, or proxy the write to the primary. ### Relevant logs and/or screenshots ``` {"severity":"ERROR","exception.class":"ActiveRecord::StatementInvalid","exception.message":"PG::ReadOnlySqlTransaction: ERROR: cannot execute UPDATE in a read-only transaction\n","exception.sql":"UPDATE "users" SET "updated_at" = $1, "failed_attempts" = $2 WHERE "users"."id" = $3","meta.caller_id":"GraphqlController#execute","exception.backtrace":["...","devise (4.9.4) lib/devise/models/lockable.rb:64:in reset_failed_attempts!'","devise (4.9.4) lib/devise/hooks/lockable.rb:7","warden (1.2.9) lib/warden/proxy.rb:191:in set_user'","app/controllers/concerns/sessionless_authentication.rb:34:in `sessionless_sign_in'","app/controllers/graphql_controller.rb:88","..."]} ``` Confirmed on the affected instance: `User.first.failed_attempts` returned `2`, `locked_at` was `nil`, and the only failing endpoint is `/api/v4/geo/node_proxy/2/graphql`; UI login (session-based) is unaffected. #### Results of GitLab environment info <details> <summary>Primary site</summary> System information System: Ubuntu 24.04 Proxy: no Current User: git Using RVM: no Ruby Version: 3.3.11 Gem Version: 3.7.1 Bundler Version:4.0.10 Rake Version: 13.4.2 Redis Version: 7.2.14 Sidekiq Version:7.3.9 Go Version: unknown GitLab information Version: 19.2.4-ee Revision: 85f4a2d9565 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 17.10 URL: http://<primary IP> HTTP Clone URL: http://<primary IP>/some-group/some-project.git SSH Clone URL: git@<primary IP>:some-group/some-project.git Elasticsearch: no Geo: yes Geo node: Primary Using LDAP: no Using Omniauth: yes Omniauth Providers: GitLab Shell Version: 14.56.1 Repository storages: - default: unix:/var/opt/gitlab/gitaly/gitaly.socket GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Gitaly - default Address: unix:/var/opt/gitlab/gitaly/gitaly.socket - default Version: 19.2.4 - default Git Version: 2.55.0-rc1.g02bb39c </details> <details> <summary>Secondary site</summary> System information System: Ubuntu 24.04 Proxy: no Current User: git Using RVM: no Ruby Version: 3.3.11 Gem Version: 3.7.1 Bundler Version:4.0.10 Rake Version: 13.4.2 Redis Version: 7.2.14 Sidekiq Version:7.3.9 Go Version: unknown GitLab information Version: 19.2.4-ee Revision: 85f4a2d9565 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 17.10 URL: http://<secondary IP> HTTP Clone URL: http://<secondary IP>/some-group/some-project.git SSH Clone URL: git@<secondary IP>:some-group/some-project.git Elasticsearch: no Geo: yes Geo node: Secondary Using LDAP: no Using Omniauth: yes Omniauth Providers: GitLab Shell Version: 14.56.1 Repository storages: - default: unix:/var/opt/gitlab/gitaly/gitaly.socket GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Gitaly - default Address: unix:/var/opt/gitlab/gitaly/gitaly.socket - default Version: 19.2.4 - default Git Version: 2.55.0-rc1.g02bb39c </details> ### Possible fixes Override `reset_failed_attempts!` in `app/models/user.rb` to no-op on read-only connections, then delegate to Devise with super: ```ruby def reset_failed_attempts! return if ::Gitlab::Database.read_only? super end ``` Place it right after the existing `increment_failed_attempts!` (before `access_level`), keeping the two Lockable-write overrides together with a short comment explaining the Geo/read-only reason. The model already guards the same class of Devise/read-only writes: - `increment_failed_attempts!` → `return if ::Gitlab::Database.read_only?` - `consume_otp!`, `invalidate_otp_backup_code!`, `remember_me!`, `forget_me!` all guard on read-only. ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status. #### High-severity bug remediation To remediate high-severity issues requiring an [internal release](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads). <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->