Every auth signup times out - GoTrue connection stuck "idle in transaction" blocking user tables

[alessanmag]

Subject: Every /auth/v1/signup request times out - GoTrue connection left "idle in transaction", blocking user_roles/user_profiles

Project ref: tvabpsxfwofiqriwbolz

Since restarting the project on 2026-08-30 (following the "Increased response times for requests" incident, resolved per your status page at 2026-08-29 01:25 UTC), every signup attempt through POST /auth/v1/signup fails with a 504 / "Context deadline exceeded" from GoTrue. This is isolated to signup - existing users can log in normally (POST /token works fine every time), and general read queries against our own tables are fast and reliable.

What I found while diagnosing:

Auth logs (Logs > Auth) show repeated entries like: 504 POST /signup - Context deadline exceeded with occasional 200 POST /signup - "User confirmation requested: request completed" mixed in - so some attempts do eventually succeed, most time out.

Querying pg_stat_activity / pg_locks during a failed attempt shows a GoTrue-owned backend connection sitting in state 'idle in transaction', running: UPDATE "users" AS users SET "raw_app_meta_data" = $1, "updated_at" = $2 WHERE users.id = $3 holding RowExclusiveLock on public.user_roles and public.user_profiles (both are populated by our handle_new_user trigger on auth.users, which is a small, fast trigger - just two single-row INSERTs, no long-running logic).

Manually running select pg_terminate_backend(pid) on that connection releases the locks and the immediate queue clears - but the very next signup attempt reproduces the same "idle in transaction" connection again. This has now happened repeatedly over the course of about an hour, so it looks like a recurring GoTrue-side issue (connections it opens for the post-signup raw_app_meta_data update are not being committed/closed), not a one-off stuck transaction on our end.

Could you check whether GoTrue on this project has connections that aren't being properly committed/released after the post-signup metadata update? Happy to provide exact pid/timestamp examples or run further diagnostics if useful.

Thanks, Alessandro Maggi

[GaryAustin1]

Do you have any auth.users trigger functions or auth hooks. Ones that especially might be doing a webhook or a pgnet/http call?

No one here can check your project you would need to file a support request.

[Bushra-KB]

This strongly points to a GoTrue-side connection leak introduced after the Aug 29 incident. The pattern you're describing — idle in transaction on the UPDATE users SET raw_app_meta_data query, holding locks on user_roles/user_profiles, reproducible on every signup — is consistent with GoTrue opening a transaction for the post-signup metadata update and not committing/rolling back it, leaving the connection open indefinitely.

A few things worth checking/trying while you wait for Supabase support to investigate GoTrue on your project:

1. Statement timeout on the auth schema — check if ALTER ROLE authenticator SET statement_timeout or idle_in_transaction_session_timeout is set (or missing). Adding idle_in_transaction_session_timeout = '30s' at the database level can automatically kill stuck GoTrue connections and unblock the queue.

ALTER DATABASE postgres SET idle_in_transaction_session_timeout = '30s';

2. Trigger deferral — if your handle_new_user trigger touches user_roles/user_profiles synchronously, try making it DEFERRABLE INITIALLY DEFERRED or moving it to a background job to reduce lock contention with GoTrue's own update.

3. Restart GoTrue — from the Supabase dashboard, go to Settings → Infrastructure → Restart services and restart the Auth service. This should flush the leaked connections without restarting the full database.

Your support ticket is the right path for the root-cause fix on GoTrue's connection handling. The idle_in_transaction_session_timeout workaround should help keep signups unblocked in the meantime.