Supabase Auth returns HTTP 500 on GET /auth/v1/user after password recovery redirect

[mmanresah]

Hi Supabase community,

I'm troubleshooting a password recovery issue in a small client-side HTML application using Supabase Auth and @supabase/supabase-js.

Expected behavior

A user requests a password recovery email, opens the recovery link, returns to the application, establishes a recovery session, and can then set a new password using supabase.auth.updateUser({ password: newPassword }).

Actual behavior

The observed sequence is:

1. POST /auth/v1/recover returns HTTP 200.
2. The recovery email is received and its link is opened.
3. GET /auth/v1/verify returns HTTP 303 and redirects to the application at http://localhost:3000/, with recovery tokens in the URL fragment.
4. During session initialization, GET /auth/v1/user returns HTTP 500.
5. The browser also reports a CORS error for the failed request.

The failing /auth/v1/user request appears to be triggered by supabase.auth.setSession() in the current implementation. I have not yet confirmed that the password update step is reached successfully.

Diagnostics already collected

• The recovery request and verification redirect complete successfully according to the observed HTTP statuses.
• The API Gateway logs identify the failing GET /auth/v1/user request.
• API Gateway log ID: 6dd70689-bffb-471d-9145-e0fabb781ae8.
• The available Auth and Postgres logs have not yet revealed the underlying cause.
• The browser's CORS message may be a consequence of the HTTP 500; this has not been established.
• No database schema or Edge Functions were changed during this investigation.

Questions

1. What could cause /auth/v1/user to return HTTP 500 immediately after a password recovery redirect when the client calls supabase.auth.setSession()?
2. What additional Auth or API Gateway logs would help identify the underlying server-side error?
3. Is there a known issue or recommended diagnostic procedure for this recovery flow in a client-side HTML application?
4. Should the session initialization error be resolved before attempting supabase.auth.updateUser({ password: newPassword })?

I would appreciate help identifying the root cause before making code or configuration changes. I can provide the Supabase JS version and further sanitized diagnostic details if needed.

Thank you for your time and help.

[somuai]

Architectural Diagnosis & Root Cause Analysis

The symptoms you are observing (GET /auth/v1/user returning HTTP 500 accompanied by a browser CORS error) are closely linked and stem from how Supabase Auth (GoTrue) handles user retrieval and how the upstream API Gateway manages error responses.

---

1. Why GET /auth/v1/user Returns HTTP 500

In the Supabase Auth architecture (GoTrue), the endpoint GET /auth/v1/user executes the following internal flow:

1. Authentication Middleware (requireAuthentication):
   GoTrue extracts and validates the Bearer JWT from the incoming request headers.
2. User & Session Loading (maybeLoadUserOrSession):
   Once the JWT signature and claims are verified, GoTrue invokes models.FindUserByID(tx, userID) using Pop/Buffalo ORM with eager loading enabled (tx.Eager("Identities")).
3. Database Query & State Assembly:
   GoTrue queries Postgres to assemble the complete user object, including its linked identities (auth.identities), factors, and metadata.

An HTTP 500 on GET /auth/v1/user occurs when an unhandled server-side exception aborts this lifecycle. In a password recovery redirect flow, the most common root causes are:

• Failing Database Triggers on auth.users:
  During verification and session recovery, GoTrue updates internal tracking columns on auth.users (such as last_sign_in_at, recovery_sent_at, or session counters). If you have custom Postgres triggers attached to auth.users (e.g. a BEFORE UPDATE or AFTER UPDATE trigger synchronizing data to public.profiles or an audit table), any exception inside that trigger function—such as a missing column, null constraint violation, or permission mismatch—will cause Postgres to abort the transaction, causing GoTrue to return an HTTP 500 Internal Server Error.
• Unhandled Auth Hooks (PL/pgSQL Functions):
  If your project has configured Supabase Auth Hooks (such as the "Custom Access Token (JWT) Hook", "MFA Verification Hook", or "Send Email/SMS Hook"), GoTrue executes the specified SQL hook function via RPC during session issuance. If the hook raises an unhandled exception or returns a schema that fails JSON validation, GoTrue fails with an HTTP 500.
• Corrupted or Duplicate Records in auth.identities:
  Because FindUserByID loads identities eagerly, duplicate identity entries (for instance, if an identity was created under both email and provider schemas without unique constraints) or orphaned identity records can cause Pop ORM to fail when unmarshaling relational rows into Go structs.
• Session Record Invariant Violations:
  If enable_manual_linking or specific session tracking settings are enabled, and the recovery token creates a session that conflicts with existing active sessions for that user ID, GoTrue can encounter an unhandled internal error.

---

2. Why the Browser Reports a CORS Error (Red Herring)

The CORS error in the browser console is a downstream symptom of the HTTP 500, not a standalone CORS configuration issue.

In Supabase, client requests first hit an API Gateway (Kong reverse proxy) before reaching the GoTrue Auth container:

• Kong is configured with a CORS plugin that dynamically injects Access-Control-Allow-Origin, Access-Control-Allow-Headers, and Access-Control-Allow-Methods headers into HTTP responses.
• When an upstream service (GoTrue) encounters an unhandled 500 Internal Server Error or crashes mid-request, Kong forwards the 500 error response without executing the standard CORS header transformation pipeline.
• Because the resulting HTTP 500 response reaches the browser without an Access-Control-Allow-Origin header, the browser's security engine blocks client JavaScript from reading the response body and outputs a CORS error in the console.

Once the underlying server-side HTTP 500 in GoTrue/Postgres is fixed, the CORS error will resolve automatically.

---

3. Answers to Your Questions

Question 1: What could cause /auth/v1/user to return HTTP 500 immediately after a password recovery redirect when the client calls supabase.auth.setSession()?

As detailed above, supabase.auth.setSession() provides the access token and refresh token to the client, which immediately triggers a background call to GET /auth/v1/user to validate the user object against the database.

The 500 error is caused by a server-side failure during that validation. The three primary culprits to investigate are:

1. A Postgres trigger on auth.users failing during the update of session or timestamp data.
2. An Auth Hook (such as a custom JWT claims hook) failing when evaluating the recovery session.
3. An issue loading relations from auth.identities for that specific user.

Question 2: What additional Auth or API Gateway logs would help identify the underlying server-side error?

To pinpoint the exact line or transaction failing:

1. Supabase Dashboard -> Logs -> Auth Logs:
   Run the following query in the Log Explorer to view GoTrue internal error messages:

   select
     timestamp,
     event_message,
     metadata
   from auth_logs
   where metadata.level = 'error'
      or event_message like '%error%'
   order by timestamp desc
   limit 50;

   Look for log lines containing error finding user, database error, or error executing hook. GoTrue prints the exact Postgres error code and error message here.

2. Supabase Dashboard -> Logs -> Postgres Logs:
   Search for errors occurring around the timestamp of Gateway Log ID 6dd70689-bffb-471d-9145-e0fabb781ae8:

   select
     timestamp,
     event_message
   from postgres_logs
   where event_message like '%ERROR%'
      or event_message like '%FATAL%'
   order by timestamp desc
   limit 50;

   This will show whether a PL/pgSQL function or trigger aborted the transaction.

3. API Gateway Logs:
   Filtering the API Gateway logs by request_id = '6dd70689-bffb-471d-9145-e0fabb781ae8' will confirm upstream_status: 500 and upstream_response_time, verifying that the error originated entirely from the upstream Auth service.

Question 3: Is there a known issue or recommended diagnostic procedure for this recovery flow in a client-side HTML application?

Yes. In client-side HTML / JavaScript SPAs, manually parsing URL hash fragments and calling supabase.auth.setSession() is prone to race conditions with the SDK's built-in auto-refresh and session detection mechanisms.

Recommended Pattern:
Allow @supabase/supabase-js to detect the recovery token automatically via onAuthStateChange:

import { createClient } from '@supabase/supabase-js';

const supabase = createClient('https://<project-ref>.supabase.co', '<anon-key>');

// Listen for Auth events automatically
supabase.auth.onAuthStateChange(async (event, session) => {
  if (event === 'PASSWORD_RECOVERY') {
    // The SDK has already parsed the URL fragment and established the recovery session.
    // Display the password reset form to the user here.
    console.log('Recovery session active for user:', session.user.id);
  }
});

Diagnostic SQL Checks:
Run these queries in the Supabase SQL Editor to check your database state:

1. Check for active triggers on auth.users:

select 
  tgname as trigger_name,
  proname as function_name,
  tgenabled as status
from pg_trigger
join pg_class on pg_trigger.tgrelid = pg_class.oid
join pg_proc on pg_trigger.tgfoid = pg_proc.oid
join pg_namespace on pg_class.relnamespace = pg_namespace.oid
where pg_namespace.nspname = 'auth' 
  and pg_class.relname = 'users';

If you find custom sync triggers (e.g. on_auth_user_updated), temporarily review their definitions to ensure they handle recovery updates gracefully (e.g. when metadata fields might be empty or unchanged).

2. Check the user's identities:

select id, user_id, provider, identity_data, created_at, updated_at
from auth.identities
where user_id = '<user-id-from-auth-logs>';

Verify that there are no duplicate entries with identical provider IDs.

Question 4: Should the session initialization error be resolved before attempting supabase.auth.updateUser({ password: newPassword })?

Yes, absolutely.

supabase.auth.updateUser() sends a PUT /auth/v1/user request that requires a valid, authenticated session. If GET /auth/v1/user is already failing with HTTP 500, calling updateUser() will also fail because:

1. GoTrue cannot authenticate and load the current user state to authorize the update.
2. updateUser() executes an UPDATE on auth.users, which will re-trigger the very same Postgres triggers or auth hooks that are causing the transaction failure.

Resolving the root cause in the Auth / Postgres logs is a mandatory prerequisite before password updates can succeed.

[mmanresah]

Update: Repeated HTTP 500 responses confirmed in API Gateway logs

I have collected additional Supabase API Gateway logs showing that this issue is reproducible across multiple password recovery attempts.

Observed request sequence:

• POST /auth/v1/recover → HTTP 200.
• GET /auth/v1/verify → HTTP 303.
• GET /auth/v1/user → HTTP 500.

Confirmed failing requests (UTC, 17 October 2026):

• 20:48:08 UTC — GET /auth/v1/user → 500.
• 20:59:55 UTC — GET /auth/v1/user → 500.
• 21:11:35 UTC — GET /auth/v1/user → 500.

The attempts used different redirect destinations, including the Netlify deployment and a local development URL (localhost:3001). Changing the redirect destination did not eliminate the HTTP 500.

The browser reports a CORS-related error, but I understand this may be secondary to the HTTP 500. The available API Gateway logs confirm the failing endpoint but do not expose the underlying Auth exception. The corresponding Postgres export did not show an obvious database error, although it contained only a limited set of events.

Could someone help determine whether these requests reached GoTrue and whether there are internal Auth errors associated with these timestamps or the corresponding request identifiers?

I have not modified the database schema, Auth configuration, Edge Functions, or application code as part of this investigation.

I can provide sanitized log excerpts and request identifiers if needed. I will not share recovery tokens or authorization headers publicly.