Diagnostic Summary for Supabase Support
Context

Issue: OTP verification fails only for brand-new users; existing users unaffected.
Hook state: The custom PG hook (public.workspace_access_token_hook) was disabled, but failures persist.
Impacted endpoint: POST /otp during “immediate_login_after_signup”.
Timeframe: Multiple occurrences within the last hour.
Observed Errors (from Auth logs)

error finding user: unexpected EOF
Unhandled server error: database error on committing or rolling back transaction: conn closed
/otp responses returning 500 unexpected_failure
Representative Log Snippets (timestamps UTC)

2025-12-23T08:16:30Z: POST /otp → 500 with error finding user: unexpected EOF
2025-12-23T08:16:46Z: POST /otp → 500 with database error on committing or rolling back transaction: conn closed
Multiple GET /user → 200 around the same periods
Auth service lifecycle events around 08:16:12Z: “GoTrue API started”, workers exiting/starting, “applying connection limits to db using the fixed strategy” with:
config_max_pool_size=10
config_max_idle_pool_size=10
server_max_conns=120
Behavioral Pattern

Failures occur specifically during the first OTP verification right after signup.
Same sessions show “immediate_login_after_signup”: true.
After the failure window, subsequent token/user operations succeed, pointing to a transient DB connection/pool state at the time of OTP DB reads/writes.
What We Already Ruled Out

Custom Auth hook: Disabled; logs still show /otp failures.
Application-layer logic: Existing users pass OTP and other Auth flows consistently.
RLS/policies: Not implicated; failures happen before any app DB access, within Auth’s internal OTP verification.
Hypothesis

Transient DB connectivity at Auth during new-user OTP verification (immediately after signup) causing:
Connection reset or pool exhaustion (PgBouncer/DB connection closed)
Commit/rollback failing at the end of OTP transaction
Contributing factors:
Recent Auth restart (observed in logs) with pool warm-up window.
Tight Auth DB connection limits (max_pool_size=10) under concurrent signups.
Overlapping flows: signup + OTP + immediate login/session writes.
Requested Investigation by Supabase Team

Auth → Postgres Connectivity
Check PgBouncer and Postgres logs around:
2025-12-23T08:16:30Z
2025-12-23T08:16:46Z
Look for:
Pool exhaustion, server conn resets, “EOF”, “conn closed”, backend terminations.
Any rolling restarts or migrations during those windows.
Auth Service State
Confirm if GoTrue was restarting around 08:16:12Z and whether its DB pool was fully re-established when /otp calls started.
Validate the configured connection limits for the Auth service; consider whether max_pool_size=10 is too low under signup bursts.
OTP Transaction Path
Trace the internal queries used by /otp for new users (auth.users lookup, factor verification, session creation) and confirm if any query retry logic exists on transient “EOF”/“conn closed”.
Verify if “immediate_login_after_signup” path does additional writes that could increase connection contention.
Infrastructure/Network
Check for network blips or DB node failover events in the same timeframe.
Verify no background workers/extensions are causing churn (e.g., lingering http/pg_net jobs).
Mitigations We Can Apply Client-Side (already proposed)

Add 1–2s delay between signup and OTP verify for new users to let pools warm.
Retry the OTP verification once after 500–800 ms on 5xx with unexpected_failure.
Stagger first-time verification calls under load.
Environment Details (from logs)

GoTrue version: v2.184.0
Auth connection limits applied with “fixed” strategy:
max_pool_size=10
max_idle_pool_size=10
conn_max_idle_time=1m
server_max_conns=120
Hook entries in logs show disabled custom hook is not the cause (failures occur without it).
What Success Looks Like

POST /otp for brand-new users consistently returns 200/redirect without “unexpected EOF” or “conn closed”.
No PgBouncer/Auth logs indicating connection resets at OTP commit time under normal signup load.
Please review the timestamps and errors above against PgBouncer/Postgres/GoTrue metrics and logs, and advise if connection limits or restarts explain the transient failures during the new-user OTP window.