Lovable preview stuck loading? Identify the failing layer first.

A loading screen can come from the preview, application code, authentication, network, or backend. Use console and network evidence before attributing it to a Supabase callback or changing auth code.

Do this first: Capture the first console error and failed request before editing authentication code. If Supabase is involved, check the installed client version and callback behavior instead of assuming a cause.

What the failure looks like.

The app loads until authentication, then the preview hangs. A browser console message such as "infinite recursion detected in policy for relation" turns a vague loading screen into a specific database and callback investigation.

Why it happens.

Supabase has documented a client deadlock associated with asynchronous API calls inside onAuthStateChange callbacks. This is distinct from a recursive row-level-security policy error. Identify the installed client version and failing request; neither diagnosis follows from a Lovable spinner alone.

Fix it without losing the task.

Open developer tools and capture the first console error and failed network request. Note whether the blank/loading state occurs before or after authentication.

If the application uses Supabase, inspect the auth callback for nested auth calls or unbounded state updates. Do not move code based only on the spinner symptom.

Reproduce with the smallest route or component and compare with a known-good version. Preserve auth settings and avoid repeatedly rebuilding or publishing while the cause is unknown.

After a targeted change, verify sign-in, callback completion, and the affected route in a fresh preview. Keep backend and preview failures distinct.

What the next AI should receive.

Affected route, preview state, first console error, failed network request, auth stage, relevant Supabase callback code if used, last working preview, and a clean-refresh verification result.

Check before restarting

Check the browser console and network response first, then identify whether the page is waiting on Lovable preview startup, application code, authentication, or a backend request.

Boundary of the evidence

A Supabase auth callback loop is only a code-level hypothesis when the project uses Supabase. A loading screen alone does not establish a Lovable platform defect or callback recursion.

Diagnostic checkpoint

Identify whether the first failure is in the preview, browser request, application route, auth callback, or backend.

How ShardStitch helps.

ShardStitch can carry exported project files, the relevant error, and the current diff into a fresh coding session. It cannot inspect a hosted Lovable preview or Supabase runtime unless you provide the available logs or code.

Research basis.

Supabase: API calls not returning and onAuthStateChange reference, checked September 28, 2026. These sources support a Supabase callback investigation, not a general Lovable defect or a recursive database-policy diagnosis. Verify applicability to the installed client.

FAQ.

Does a Lovable loading screen prove Supabase auth is looping?

No. The spinner could originate in the preview, application code, network, or backend. Check console and network evidence before attributing it to an auth callback.

Can ShardStitch read a hosted Lovable preview error automatically?

No. Provide the exported project files and the relevant console or network output. A local project handoff does not grant access to the hosted preview runtime.

Scope note: Evidence boundary: this page describes a diagnostic hypothesis for an app that uses Supabase Auth, not a verified general Lovable outage. Confirm the failing layer from console, network, and project code before changing auth callbacks.