DEV Community: Mahdi BEN RHOUMA

Test Supabase RLS Policies Before You Ship

Mahdi BEN RHOUMA — Mon, 24 Aug 2026 21:19:33 +0000

There is a specific way RLS bugs reach production, and it is almost never that
the developer forgot to write a policy. It is that the policy was tested in a
context that does not enforce it.

Three contexts, all of them defaults:

The Supabase SQL editor runs your query as a privileged role.
The service key you use in server-side code carries BYPASSRLS.
The owner of the table — the role your migrations run as — is exempt from its own policies unless you explicitly say otherwise.

In all three, select * from documents returns every row whether your policy
is correct, inverted, or absent. Then the same query runs from a browser with
an anon key and returns nothing, or worse, returns everything.

Why Postgres skips your policy

Row level security has two exemptions built into the engine, and they exist for
good operational reasons — backups and migrations would be miserable otherwise.

The first is the superuser exemption: any role with rolsuper, and any role
with the BYPASSRLS attribute, skips policy evaluation entirely. Supabase
creates service_role with exactly that attribute, which is the whole reason
server-side code with the service key can read across all tenants. It is also
why "it works with the service key" is not a passing test — see
service_role bypasses RLS for what
that key can reach and how to contain it.

The second is the owner exemption: the role that owns a table is not subject
to that table's policies by default. This one surprises people, because it means
the connection your migration tool uses, and the connection most SQL consoles
use, sees straight through RLS.

You turn the owner exemption off per table:

alter table public.documents force row level security;

FORCE is a table-level setting, not a session one. It does not affect
superusers or BYPASSRLS roles — nothing does. To escape those, you have to
stop being them.

The procedure

Four statements. Everything else is detail.

begin;

-- 1. Feed the JWT the policy will read. `true` = transaction-local.
select set_config(
  'request.jwt.claims',
  '{"sub":"11111111-1111-1111-1111-111111111111","role":"authenticated"}',
  true
);

-- 2. Stop being the owner.
set local role authenticated;

-- 3. Run the exact query your client runs.
select id, title from documents order by id;

rollback;

The rollback matters more than it looks. It discards the role change, the
claims, and anything the statement wrote — which is what lets you test an
INSERT repeatedly against identical seed data instead of accumulating junk
rows between runs.

auth.uid() is not magic. In a Supabase project it is a small SQL function that
reads request.jwt.claims and pulls sub out of it. Setting that GUC by hand is
precisely what PostgREST does for you when a request arrives with a bearer token,
which is why this test reproduces the real path rather than approximating it.

Run it as more than one person

This is the step almost everyone skips, and it is the one that catches actual
leaks.

A policy like using (true) passes a single-user test perfectly: you are signed
in, you asked for your rows, you got rows. The test only fails when a second
identity runs the same query and gets the same rows back.

So run the block above at least three times — once with no claims and
set local role anon, once as user A, once as user B — and compare:

Identity	Expected on a correctly scoped table
`anon`	zero rows
user A	only A's rows
user B	only B's rows, and not A's
`service_role`	everything, always — this is not a signal

If A and B see the same non-empty set, you have a cross-tenant leak. If both see
zero, you have the silent failure covered in
why RLS returns zero rows with no error.

Doing all four at once

Typing that transaction four times per policy change is why the step gets
skipped, so I built the tool I wanted: the
Supabase RLS Playground boots a real
PostgreSQL engine compiled to WebAssembly inside the browser tab, applies your
schema and your CREATE POLICY statements, and runs one query four times — as
anon, as two different signed-in users, and as service_role — showing the
four result sets side by side.

It does the two things this article is about, because otherwise it would lie to
you the same way the SQL editor does: every persona query runs under SET LOCAL ROLE, and every RLS-enabled table gets FORCE ROW LEVEL SECURITY before the
first query runs. The auth schema is shimmed the way Supabase defines it —
auth.uid(), auth.jwt(), auth.role(), auth.email() — so a policy pasted
straight out of your project runs verbatim.

Nothing is uploaded; there is no server component to upload it to. Once the
WebAssembly build is cached the page works offline.

What the measurements look like

Two experiments against a real Postgres engine, because the two exemptions
behave differently and the difference decides which flag you need.

The owner exemption, isolated. A table owned by an ordinary non-superuser
role, RLS enabled, and a policy deliberately written to match nothing —
using (user_id = 'nobody'). Queried by the owner:

Setting	Rows returned to the owner
`enable row level security` only	2 of 2 — the policy is skipped entirely
`+ force row level security`	0 — the policy applies

A policy that blocks everything returns everything, until FORCE.

The four identities, on a normal policy. Three rows in documents, two
owned by user A and one by user B, with the textbook rule
for select to authenticated using ((select auth.uid()) = user_id):

Identity	Rows
`anon`	0
user A	2
user B	1
`service_role`	3
the superuser connection, no `SET ROLE`	3

Same policy, same data, five different answers depending only on who asked. The
last two rows of that table are the ones you get by default from a SQL console
and from server-side code holding the service key — and they are the two that
tell you nothing, because neither of them ever consulted the policy.

Note which flag fixes which: FORCE removes the owner exemption, and nothing
removes the superuser exemption. To escape that one you have to stop being a
superuser, which is what SET LOCAL ROLE is for. You need both.

Studio impersonation is closer, but it is still not production

Supabase Studio has a role-impersonation feature in the SQL editor, and it is a
genuine improvement over running as the owner. Treat it as a good approximation
rather than a proof, because it is reproducing production behaviour rather than
being it.

A concrete example: supabase/supabase#27841
reported that impersonation did not invoke the project's Custom Access Token
Hook, so claims the hook adds to app_metadata were missing from
select auth.jwt() during impersonation while being present in production. That
specific gap was addressed in a later pull request — the durable lesson is not
that one bug existed, but that the JWT your test sees and the JWT your users
carry are assembled by different code paths, and any policy keyed on a custom
claim is only as trustworthy as the claim you fed it.

Which is also the argument for setting request.jwt.claims explicitly, as above:
you know exactly what the policy read, because you wrote it.

Put it in CI

Everything here runs in plain SQL, so it belongs in a migration test rather than
in your memory. The shape that works:

begin;
  select set_config('request.jwt.claims', '{"sub":"...A...","role":"authenticated"}', true);
  set local role authenticated;

  -- Fails the migration if the policy ever stops isolating users.
  do $$
  declare visible int;
  begin
    select count(*) into visible from documents where user_id <> '...A...'::uuid;
    if visible > 0 then
      raise exception 'RLS leak: user A can see % foreign rows', visible;
    end if;
  end
  $$;
rollback;

A policy change that reintroduces a leak then fails a deploy instead of failing a
customer. For the wider set of things worth asserting before a release, the
RLS debug checklist
covers the GRANTs, the session plumbing and the cache behaviour that sit around
the policies, and
RLS policy design patterns covers
the shapes that survive multi-tenancy.

The short version

Testing an RLS policy means answering one question: what does someone who is not
me get back? Any context that answers with your own privileges — the SQL editor,
the service key, the table owner — has not answered it.

Two flags and one transaction fix that. And if the policy you are testing throws
infinite recursion detected in policy for relation, that is a different
problem with a known shape:
fix infinite recursion in a Supabase policy.
For everything else that goes wrong on the way,
debugging Supabase RLS issues walks the
full failure catalogue.

Originally published at https://www.iloveblogs.blog

Supabase 42501: permission denied for schema auth

Mahdi BEN RHOUMA — Mon, 24 Aug 2026 21:18:51 +0000

Three different attempts, one error:

ERROR: 42501: permission denied for schema auth

A client-side supabase.from('users') pointed at the wrong schema. A view you
created over auth.users that works in the SQL editor and 42501s from the app.
A row level security policy that joins auth.users to check something about the
caller. All the same underlying refusal, and all fixed the same way — which is
not the way most search results suggest.

This is a boundary, not an oversight

Supabase's troubleshooting guide for 42501 errors on the database API
is explicit: the managed schemas — auth, vault — cannot be accessed directly
through the data API for security reasons, and are reachable only through
security definer functions.

The auth schema holds auth.users, which contains every account's email,
phone number, hashed password, provider identities, and raw metadata. The API
roles are the ones your browser key resolves to. Keeping one out of reach of the
other is the point.

That is why this error behaves differently from its more familiar sibling. When
anon loses its grants on the public schema you have a broken project, and
restoring the grants is the fix — that case is
permission denied for schema public.
When anon is refused on auth, the project is behaving correctly.

So the tempting one-liner:

-- Do not do this.
grant usage on schema auth to anon, authenticated;

does make the message disappear. It also means the only thing standing between a
key published in your JavaScript bundle and the user table is whatever table
grants remain. Every subsequent mistake — a permissive policy, a view, a
function that forgets to filter — becomes a full account dump.

Where each failure actually comes from

A client query against auth.users

supabase.from('users') resolves against the exposed schema (public by
default), so it usually fails with relation "public.users" does not exist
rather than 42501. Explicitly reaching for the auth schema — through
.schema('auth'), a Postgres view, or raw SQL over a direct connection — is what
produces the permission error.

There is no configuration that makes this work safely. Move the data instead.

A view over auth.users

This one deserves care, because the intuitive version of the story is backwards
and the backwards version is the dangerous one.

create view public.user_emails as
  select id, email from auth.users;

PostgreSQL's default for views is definer semantics: the view's underlying
query is checked against the view owner's privileges, not the caller's. So this
view, created by a privileged role, does not 42501 when authenticated selects
from it. It works. It hands out every email address in your project through the
data API, and the auth schema restriction you were relying on is simply routed
around.

I verified both branches against a real Postgres engine — a table in a schema the
calling role has no USAGE on, exposed through two views:

View	Declared	Result as the API role
`v_default`	nothing (definer, the default)	2 rows returned
`v_invoker`	`with (security_invoker = true)`	`permission denied for table users`

Supabase's own database linter flags exactly this as
0010_security_definer_view,
noting that Postgres's default setting for views is SECURITY DEFINER, which
means they use the permissions of the view's creator rather than the querying
user — and recommending with (security_invoker = on) so RLS applies normally.

Which reframes the error. If your view over auth.users returns 42501, it is
almost certainly declared security_invoker = true — that is, it is the
correctly configured view, and the boundary is doing its job. The fix is not to
remove security_invoker; that would trade an error message for a data leak.
The fix is one of the two patterns below.

A policy that joins auth.users

-- 42501 when evaluated as anon/authenticated.
create policy "admins can read everything"
on documents
for select
to authenticated
using (
  exists (
    select 1 from auth.users u
    where u.id = auth.uid()
      and u.raw_app_meta_data ->> 'role' = 'admin'
  )
);

Policies are evaluated as the calling role. The calling role cannot see the
auth schema, so the policy itself errors rather than returning false.

Note the asymmetry that confuses people: auth.uid(), auth.jwt() and
auth.role() are functions that Supabase grants to the API roles, so calling
them from a policy is fine. Selecting from the auth.users table is not. If
you need a claim, read it out of the JWT you already have:

using ( (auth.jwt() -> 'app_metadata' ->> 'role') = 'admin' )

That version needs no access to the auth schema at all, and it is cheaper —
no subquery per row.

If you want to see the difference between those two policies actually execute
rather than take my word for it, both run in the
Supabase RLS Playground, which applies your
policies against a real Postgres engine in the browser and runs them as anon,
as two signed-in users and as service_role.

The fix: a security definer function

When you genuinely need data that only lives in auth.users, expose the minimum
through a function that runs as its owner:

create or replace function public.current_user_email()
returns text
language sql
security definer
set search_path = ''
stable
as $$
  select email from auth.users where id = (select auth.uid());
$$;

revoke all on function public.current_user_email() from public;
grant execute on function public.current_user_email() to authenticated;

Four things make this safe, and all four matter:

security definer — the function body runs with the owner's privileges, so it can read the auth schema.
set search_path = '' — pins resolution so a caller cannot shadow auth.users with an object of their own. A security definer function without a pinned search path is a privilege escalation waiting to be found. Fully qualify every name in the body when you do this.
The where clause — the function returns the caller's row, not an arbitrary one. A definer function that takes a user id parameter and returns that user's email is a lookup oracle for your whole user table.
revoke then grant execute — you decide who can call it, rather than inheriting public.

The better fix: stop needing the auth schema

Most applications that reach for auth.users want a display name, an avatar and
an email next to their own rows. Join a table you own instead:

create table public.profiles (
  id          uuid primary key references auth.users on delete cascade,
  email       text,
  full_name   text,
  avatar_url  text,
  updated_at  timestamptz default now()
);

alter table public.profiles enable row level security;

create policy "read own profile"
on public.profiles
for select
to authenticated
using ( (select auth.uid()) = id );

-- Populate it as accounts are created.
create or replace function public.handle_new_user()
returns trigger
language plpgsql
security definer
set search_path = ''
as $$
begin
  insert into public.profiles (id, email, full_name, avatar_url)
  values (
    new.id,
    new.email,
    new.raw_user_meta_data ->> 'full_name',
    new.raw_user_meta_data ->> 'avatar_url'
  );
  return new;
end;
$$;

create trigger on_auth_user_created
  after insert on auth.users
  for each row execute function public.handle_new_user();

Now every query your client makes stays inside public, joins work normally,
RLS applies the way it does everywhere else, and the auth schema stays sealed.

Two operational notes. The trigger runs inside the signup transaction, so if it
raises, the signup fails with Database error saving new user — a distinct
failure with its own causes, covered in
the trigger rollback fix.
And existing accounts need a one-time backfill; the trigger only fires on new
inserts.

Checklist

Error mentions schema auth → you are crossing a deliberate boundary. Never grant your way through it.
Need a claim (role, tenant, email) → read auth.jwt(); no auth schema access required.
Need a column that only exists on auth.users → security definer function, search_path pinned, scoped to the caller.
Need it joined to your own data → mirror it into public.profiles with a trigger.
Error mentions schema public instead → different problem, different fix: permission denied for schema public.
Query succeeds but returns nothing → not a permission error at all, that is RLS filtering silently.

For the wider set of policy shapes that survive multi-tenancy without reaching
into managed schemas,
RLS policy design patterns is the
companion piece.

Originally published at https://www.iloveblogs.blog

Supabase Hangs After onAuthStateChange: The Deadlock

Mahdi BEN RHOUMA — Mon, 24 Aug 2026 21:18:45 +0000

The bug report is always the same shape, and it never mentions authentication:

After a while, every Supabase query in the app just hangs. No error, nothing
in the network tab. Reloading fixes it for about an hour.

Nothing rejects, so there is nothing to catch. The promise from
supabase.from('profiles').select() simply never settles. Your try/catch is
irrelevant, your error boundary never renders, and your loading state stays true
forever.

If your app calls anything on the Supabase client inside an
onAuthStateChange callback, that is the cause, and it is documented.

The mechanism

supabase-js serialises auth events. When a session changes — sign-in,
sign-out, and the hourly token refresh — the client takes an internal lock,
delivers the event to every subscriber, and releases the lock when the callbacks
have returned.

Any Supabase call you make needs that same lock, because it has to resolve the
current access token before it can attach it to the request.

So this:

supabase.auth.onAuthStateChange(async (event, session) => {
  if (session) {
    // waits for a lock this callback is already holding
    const { data } = await supabase
      .from('profiles')
      .select('*')
      .eq('id', session.user.id)
      .single();

    setProfile(data);
  }
});

…waits, inside the lock, for the lock. The callback cannot return until the
query resolves; the query cannot resolve until the callback returns.

Supabase's own troubleshooting entry,
Why is my supabase API call not returning?,
states it plainly: there is a bug in supabase-js which results in a deadlock if
any async API call is made in onAuthStateChange code, and if a call is made in
the handler then the next Supabase call anywhere using that client will hang and
not return. The tracking issue is
supabase/auth-js#762.

That second half is what makes it so hard to attribute. The deadlock does not
stay in the callback. Every later call on that client — a query in a completely
unrelated component, a getSession() in your middleware helper, a realtime
subscribe — queues behind a lock that will never be released.

Why it looks intermittent

Three events run through the same callback: SIGNED_IN, TOKEN_REFRESHED, and
INITIAL_SESSION.

Access tokens are short-lived and refreshed automatically, so
TOKEN_REFRESHED fires roughly every hour for an open tab. An app can therefore
work perfectly through a morning of navigation and then freeze at 11:04 with no
deploy, no config change and no error — which is exactly how it gets
misdiagnosed as a network problem, a Vercel cold start, or a Supabase incident.

The same timing explains the "reloading fixes it" report: a reload builds a fresh
client with a fresh lock.

The fix

Keep the callback synchronous with respect to Supabase. Set your state, then let
the work happen after the callback has returned.

supabase.auth.onAuthStateChange((event, session) => {
  // Synchronous: safe, and this is all most apps actually need here.
  setSession(session);

  if (!session) {
    setProfile(null);
    return;
  }

  // Deferred: runs on the next macrotask, after the lock is released.
  setTimeout(() => {
    void loadProfile(session.user.id);
  }, 0);
});

setTimeout(..., 0) is not a superstition here. It moves the query into a later
task, after onAuthStateChange has returned and released the lock. A
microtask — Promise.resolve().then(...), or just dropping the await — is not
reliably enough, because microtasks can drain before the synchronous caller
finishes unwinding.

In React the cleaner version avoids the timer entirely: store the session in
state and let a separate effect do the fetching.

useEffect(() => {
  const { data: sub } = supabase.auth.onAuthStateChange((_event, session) => {
    setSession(session);           // nothing but state
  });
  return () => sub.subscription.unsubscribe();
}, []);

useEffect(() => {
  if (!session?.user) return;
  let cancelled = false;

  supabase
    .from('profiles')
    .select('*')
    .eq('id', session.user.id)
    .single()
    .then(({ data }) => {
      if (!cancelled) setProfile(data);
    });

  return () => { cancelled = true; };
}, [session?.user?.id]);

Two effects, one job each. The subscription only ever touches React state, and
the query runs in a normal render cycle where nothing holds the auth lock.

What still counts as "a Supabase call"

The rule is broader than .from(). Inside the callback, avoid awaiting:

supabase.from(...), .rpc(...), .storage.from(...) — anything that needs a token
supabase.auth.getSession() and supabase.auth.getUser() — you already have the session as the second argument; use it
supabase.auth.refreshSession(), setSession(), signOut()
anything that transitively calls one of the above, including your own fetchProfile() helper or a data-layer wrapper

Calls to your own API routes are fine, as long as they do not funnel back through
the same browser client.

Confirming it is this and not something else

Two checks, thirty seconds each.

One. Comment out the body of your onAuthStateChange callback, leaving only
a console.log. If the hangs stop, you have your answer.

Two. Instrument the boundary — if the first line logs and the second does
not, the query never settled:

supabase.auth.onAuthStateChange(async (event, session) => {
  console.log('[auth] callback in', event);
  const { data } = await supabase.from('profiles').select('id').limit(1);
  console.log('[auth] callback out', data);   // never prints when deadlocked
});

A hang with in and no out is a deadlock. An error in between is a different
bug — probably RLS or a missing session, and
debugging Supabase RLS issues covers that
path.

Related failures that look identical from the outside

"Supabase stopped working after a while" has a small family of causes, and they
are worth ruling out in order:

The session is not being persisted or refreshed across navigations — fix Supabase auth session persistence.
Cookies are set in the wrong place for the App Router, so the server and the client disagree about who is signed in — the complete session and middleware guide and SSR session management.
The redirect after sign-in lands on a URL that never receives the session — Supabase auth redirect fix.
The console is full of the getUser() security warning, which is a different message about a different mistake — fix the Supabase getUser warning.

The deadlock is the one that produces silence rather than a message. If nothing
is logged, nothing is thrown, and nothing appears in the network tab, look at
what your auth callback is awaiting.

Originally published at https://www.iloveblogs.blog

Fix AuthSessionMissingError: Auth session missing!

Mahdi BEN RHOUMA — Mon, 24 Aug 2026 21:18:03 +0000

AuthSessionMissingError: Auth session missing!

That string comes from @supabase/auth-js, not from the Supabase API. The SDK
raises it locally, before any network request, whenever a method that needs a
session cannot find one. Reading it as "Supabase is broken" sends you looking in
the wrong place; reading it as "this particular client object is empty" sends you
straight to the cause.

There are four ways a client ends up empty, and they need four different fixes.

First: which call produced it?

The SDK is not consistent about how it surfaces this, and the inconsistency
causes real bugs.

getUser() returns the error:

const { data, error } = await supabase.auth.getUser();
// data.user === null
// error?.name === 'AuthSessionMissingError'

updateUser(), setSession() and refreshSession() throw it.

So this code is wrong in a way that will not show up until production:

try {
  const { data } = await supabase.auth.getUser();
  renderDashboard(data.user);      // data.user is null, no exception was thrown
} catch (e) {
  redirectToLogin();               // never runs
}

Check the error value, or check data.user for null. A try/catch alone will
walk a signed-out visitor straight into your authenticated UI.

Cause 1: a server client built without cookies

This is the App Router classic, and it accounts for most of the reports.

In the browser, the Supabase client persists the session in localStorage and
finds it there on the next call. On the server there is no localStorage and no
ambient state — a server-side client only knows what you hand it. If you create
it with the anon key and nothing else, it has no session by construction, and
every getUser() returns Auth session missing! no matter who is signed in.

The server client must be built from the incoming request's cookie store:

// utils/supabase/server.js
import { createServerClient } from '@supabase/ssr';
import { cookies } from 'next/headers';

export async function createClient() {
  const cookieStore = await cookies();

  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll();
        },
        setAll(cookiesToSet) {
          try {
            cookiesToSet.forEach(({ name, value, options }) =>
              cookieStore.set(name, value, options),
            );
          } catch {
            // Called from a Server Component: middleware handles the refresh.
          }
        },
      },
    },
  );
}

Two details people trip on. cookies() must be awaited in current Next.js
versions — if you have older code destructuring it synchronously, that is a
separate error worth fixing at the same time. And the try/catch around
setAll is deliberate: Server Components cannot write cookies, so the write
throws there and middleware has to do the refreshing instead.

Full wiring, including the client/server split and the route handler cases, is in
the complete Supabase session and middleware guide.

Cause 2: no middleware refreshing the session

Access tokens are short-lived. The browser client refreshes them on its own
timer; the server has no timer, so it depends on middleware running on each
request to exchange the refresh token and write the new cookies back.

Without it the failure is time-dependent, which is why it reads as flaky: sign
in, everything works, come back an hour later and every server render reports
Auth session missing! while the browser tab still believes it is signed in.

The middleware must both read and write:

// middleware.js
import { createServerClient } from '@supabase/ssr';
import { NextResponse } from 'next/server';

export async function middleware(request) {
  let response = NextResponse.next({ request });

  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll();
        },
        setAll(cookiesToSet) {
          cookiesToSet.forEach(({ name, value }) => request.cookies.set(name, value));
          response = NextResponse.next({ request });
          cookiesToSet.forEach(({ name, value, options }) =>
            response.cookies.set(name, value, options),
          );
        },
      },
    },
  );

  // This call is what performs the refresh. Do not remove it.
  await supabase.auth.getUser();

  return response;
}

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
};

Returning a response object that is not the one the cookie writer mutated is
the subtle way to break this: the refreshed cookies get written to an object you
then discard, and the browser never receives them. The symptom is identical to
having no middleware at all.

Cause 3: reading the session too early on the client

On first paint the browser client has not finished restoring the session from
storage. A getUser() fired at module scope, or in a component body rather than
an effect, can run before the restore completes and report the session as
missing — then a re-render a moment later shows it present.

Subscribe rather than poll:

useEffect(() => {
  supabase.auth.getUser().then(({ data }) => setUser(data.user));

  const { data: sub } = supabase.auth.onAuthStateChange((_event, session) => {
    setUser(session?.user ?? null);
  });

  return () => sub.subscription.unsubscribe();
}, []);

One warning: do not await other Supabase calls inside that callback. It
deadlocks the client and every later query hangs forever — the mechanism and the
fix are in
Supabase hangs after onAuthStateChange.

Cause 4: nobody is signed in

The dull answer, and often the right one.

For a visitor who never signed in, or who just signed out, Auth session missing! is the correct and expected result. If it is filling your logs, the
problem is that your code treats a normal state as an exception:

const { data, error } = await supabase.auth.getUser();

if (!data.user) {
  redirect('/login');           // not an error path — a branch
}

if (error && error.name !== 'AuthSessionMissingError') {
  captureException(error);      // this one is a genuine failure
}

Filter the expected case out of your error reporting and the remaining
occurrences become meaningful again.

A quick way to tell the causes apart

Log one line in the failing server-side code path:

const store = await cookies();
console.log('[auth] cookies seen:', store.getAll().map((c) => c.name));

No sb-…-auth-token cookie at all — the browser never sent one. The visitor is signed out (cause 4), or the sign-in redirect never landed on your origin: see the Supabase auth redirect fix.
Cookie present, still missing on the server — the client was built without the cookie store (cause 1).
Cookie present but stale, and it only fails after a while — middleware is missing or discarding the refreshed response (cause 2).

Related failures with different messages

Once a session exists, the next class of problem is what that session is allowed
to read. An authenticated request that returns zero rows is not an auth problem
at all — that is row level security filtering silently, covered in
why RLS returns zero rows, and you
can reproduce your own policy against real Postgres in the
RLS Playground.

Two adjacent messages worth not confusing with this one: the
getUser() security warning, which is about
trusting getSession() on the server, and
session persistence failures,
where the session exists but does not survive navigation.

Originally published at https://www.iloveblogs.blog

Better Auth vs Supabase Auth 2026: Honest Verdict

Mahdi BEN RHOUMA — Mon, 24 Aug 2026 21:17:56 +0000

Most comparisons of these two list sign-in methods side by side, notice that
both support email, OAuth, magic links and passkeys, and conclude that it is a
matter of taste.

It is not a matter of taste. There is one decision underneath, and it is
architectural: where is authorisation enforced?

Supabase Auth exists to put an identity inside the database, so that Postgres
itself can decide what a request may read. Better Auth exists to put identity
inside your application, so that your TypeScript code can decide. Everything
else — the provider list, the plugin catalogue, the pricing — follows from that
and matters far less.

The mechanism you are actually choosing between

Supabase Auth: the database knows who you are

When a Supabase client makes a request, it carries a JWT signed with your
project's secret. PostgREST validates it, sets the Postgres role from the
token's role claim, and puts the whole claim set into a session variable.
auth.uid() is then a small SQL function that reads sub out of that variable.

That is the entire trick, and it is why a row level security policy can say:

create policy "read own documents"
on documents
for select
to authenticated
using ( (select auth.uid()) = user_id );

The consequence is real: a developer who forgets a where user_id = ... in a
query does not leak data, because the database refuses the rows regardless. Your
authorisation rules live in one place, next to the data, and apply to every
client that ever connects — your web app, your mobile app, a script someone runs
at 2am.

The cost is that those rules are written in SQL, are awkward to unit test, and
fail in ways that are quiet by design. That is why I built the
RLS Playground — it runs a real Postgres engine
in the browser and executes your policies as anon, as two different signed-in
users and as service_role, side by side, so "does this policy actually isolate
tenants?" becomes a question you answer by looking rather than by reasoning.

Better Auth: your application knows who you are

Better Auth describes itself as a framework-agnostic authentication and
authorisation framework for TypeScript, with database management and migrations
handled for you and capabilities such as two-factor, organisations, rate
limiting and access control available in the core or as plugins.

Practically, it means users and sessions become ordinary tables in your
database. You can join them. You can migrate them with the rest of your schema.
You can read them in a test without mocking a network service. Your getSession()
is a database read in your own process, not a round trip to an identity
provider.

Authorisation then happens in your server code — in a service layer, a
middleware, or whatever pattern your team already uses. It is easy to test,
easy to express complex rules in, and completely dependent on every query going
through it. A raw query written in a hurry bypasses the whole thing.

The mistake to avoid: assuming they compose

The tempting architecture is Better Auth for identity, Supabase for the
database. It is a reasonable thing to want, and it works — but not by default,
and the failure mode is silent.

Two cases:

You connect to Postgres directly from your server, with Drizzle or Prisma
over a normal connection. That connection authenticates as a database user of
your choosing, not as authenticated, and no JWT claims are set. Your RLS
policies are simply not consulted in any meaningful way, and if the role is the
table owner or a superuser they are skipped entirely. Everything appears to
work — because every query returns everything.

You go through PostgREST (the supabase-js client). Then the request needs
a JWT signed with your project's secret and carrying sub and role, or the
API rejects it. Minting one from Better Auth is possible, but you are now
maintaining a token bridge and two sources of truth about session lifetime and
revocation.

If you choose this combination, decide deliberately which of the two you are
doing, and write it down. The version I would avoid is drifting into case one
while still believing RLS protects you. The
testing procedure here will
tell you within a minute whether your policies are being enforced at all.

Where each one is clearly right

Supabase Auth is the right call when:

You already run Supabase. Auth is provisioned, and storage, realtime and the auto-generated API all expect its JWTs. Replacing it means replacing their authorisation model too.
Authorisation is data-shaped: rows belong to users, users belong to organisations, and the rules are expressible as predicates. See RLS policy design patterns.
More than one client will reach the database, and you want the guarantee to hold for all of them rather than trusting each one.
You want the shortest path from zero to a working signed-in app — the complete Supabase auth guide for Next.js is roughly an afternoon.

Better Auth is the right call when:

Your database is your own Postgres — Neon, Hetzner, Scaleway, RDS, whatever — and you have no intention of adopting the rest of the Supabase platform.
Authorisation is behaviour-shaped rather than row-shaped: quotas, workflow states, plan limits, per-endpoint permissions. Expressing those in SQL policies is possible and unpleasant.
You want auth in your repository, reviewable in pull requests and testable in CI, rather than configured in a dashboard.
Cost predictability at scale matters. Users in your own tables have no monthly-active-user tier to cross.

The parts that do not decide it

A few axes get more attention than they deserve.

Provider coverage. Both do email and password, the mainstream OAuth
providers, magic links, OTP and passkeys. Check the specific niche provider you
need; otherwise this is a tie.

Organisations and RBAC. Better Auth ships organisation and access-control
capability as part of the framework. Supabase gives you tables and policies and
expects you to build the model — which is more work up front and completely
yours afterwards. See
multi-tenant SaaS architecture on Supabase
for what that build looks like.

Lock-in. Both store users in Postgres, so in either case you can export the
table. What is not portable is the authorisation layer: RLS policies assume
Supabase-minted JWTs, and application-layer rules assume your session object.
Migrating auth is cheap; migrating enforcement is not.

A note for EU teams

If you are handling personal data under the GDPR, the question is where the
identity records physically live.

With Better Auth they live in your database, so an EU-hosted Postgres keeps them
in the EU and adds no additional processor to your record of processing
activities. With Supabase Auth they live in your Supabase project — fine for EU
residency provided you pick an EU region when you create the project, since
the region cannot be changed later. Migrating a live project across regions is
a data migration, not a setting.

Either way, both give you the account deletion primitive you need for erasure
requests; with Better Auth it is a delete in your own schema, and with Supabase
it is an admin API call plus whatever cascades you defined on your own tables.

The verdict

Ask one question: if a developer on your team writes a query without a
where clause on the tenant column, what stops the leak?

If the answer needs to be "the database", you want Supabase Auth, and you should
invest the afternoon it takes to test your policies properly rather than
assuming them. If the answer can be "our service layer, which is reviewed and
tested", Better Auth gives you a cleaner, cheaper, more testable system that
lives entirely in your repository.

Both are good. They are good at different things, and the thing they differ on
is not one you can change later without a rewrite.

For the third option in this space — a managed provider that owns the identity
layer entirely — the trade-offs are laid out in
Supabase Auth vs Clerk,
and the wider field is surveyed in
Next.js auth in 2026.

Originally published at https://www.iloveblogs.blog

Switch Databases in psql: The \connect Command (2026)

Mahdi BEN RHOUMA — Fri, 21 Aug 2026 21:14:18 +0000

The muscle-memory trap

You came from MySQL. You opened psql, ran \l to list databases, and typed
USE mydb;. psql replied with:

mydb=> use mydb;
ERROR:  syntax error at or near "use"
LINE 1: use mydb;

There is no USE in PostgreSQL, and there is no in-session database switch.
Each PostgreSQL database is an isolated connection target. Switching databases
means opening a new connection, and psql gives you one meta-command for it:
\connect, abbreviated \c.

This is one of the highest-traffic psql questions on Stack Overflow (the
"switch databases in psql" thread has 1.3M+ views) precisely because of that
MySQL muscle memory.

The command

\c dbname

or the long form:

\connect dbname

psql prints the new connection prompt:

postgres=> \c mydb
You are now connected to database "mydb" as user "postgres".
mydb=>

The prompt changes to reflect the database you are in. Your current session
state — temporary tables, SET variables, prepared statements — is gone,
because it is a brand new connection.

Switch user, host, or port at the same time

\c accepts a full connection spec. You can switch to a different database
and a different user in one command:

\c dbname newuser
\c dbname newuser newhost 5433

When you omit the user, psql reuses the current one. When you omit host and
port, it reuses the current connection's. If the new database needs a password,
psql prompts for it (or uses the PGPASSWORD env var / ~/.pgpass file).

The transaction gotcha

You cannot switch databases inside an open transaction:

mydb=> BEGIN;
BEGIN
mydb=*# \c otherdb
FATAL:  terminating connection due to administrator command
could not connect to server: ...

Some psql versions phrase it as "there is a transaction in progress". Either
way the rule is the same: finish the transaction first.

mydb=*# COMMIT;   -- or ROLLBACK
COMMIT
mydb=# \c otherdb
You are now connected to database "otherdb".

This exists because switching databases silently drops the connection — and
PostgreSQL will not let uncommitted work vanish without an explicit decision.

Connect at launch instead

If you know the database up front, skip \c entirely and connect at launch:

psql -d mydb
psql -d mydb -U app_user -h localhost -p 5432

or with a connection string (the form Supabase gives you):

psql "postgresql://user:pass@host:5432/mydb"

For the common "list databases, pick one, connect" flow, the sequence is:

\l              -- list databases
\c target_db    -- connect to the one you want
\dt             -- list tables in the new database

Once you are in, the tables are not in a single list you can scan without
context — see show tables in PostgreSQL
for the full \dt, \d, and information_schema walkthrough, and the
PostgreSQL DESCRIBE TABLE equivalent
for inspecting columns.

Exit psql

While we are on meta-commands: to leave psql, it is \q (or Ctrl+D):

mydb=> \q

Not exit, not quit — though recent psql versions accept those as aliases.
\q works everywhere.

Supabase: connect to a specific project

Supabase exposes a Postgres database per project. From the dashboard:

Project Settings → Database → Connection string → URI

Copy it (the pooling variant, port 6543, is what you want for CLI work):

psql "postgresql://postgres.[ref]:[password]@aws-0-[region].pooler.supabase.com:6543/postgres"

You land in the postgres database — the only user database. There is rarely
a reason to \c to another database on Supabase; you switch between schemas
(public, auth, storage) with SET search_path, not databases:

SET search_path TO public, auth;
SELECT * FROM auth.users;

If you need to reset the password on that connection, the
change PostgreSQL user password guide
covers the ALTER ROLE flow that works on Supabase too.

Common mistakes

Typing USE dbname. There is no USE in psql. It is \c dbname.
Switching inside a transaction. COMMIT or ROLLBACK first.
Forgetting the prompt change. The prompt shows the current database; if your queries hit the wrong tables, check it.
Mixing up database and schema. On PostgreSQL (and Supabase) you usually want to switch schema with SET search_path, not database with \c.
Connecting on port 5432 to Supabase. That is the direct connection; use 6543 (pooler) unless you need a feature PgBouncer does not support.

Originally published at https://www.iloveblogs.blog

How to Drop All Tables in PostgreSQL Safely (2026)

Mahdi BEN RHOUMA — Fri, 21 Aug 2026 14:32:35 +0000

Why you are here

You ran a migration that went sideways, or you are resetting a local dev
database, or a test suite needs a clean slate. The psql console has 40 tables
and you do not want to type DROP TABLE 40 times.

There is a one-command way to do it. There is also a PostgreSQL 15 change that
silently breaks it the first time you try, and a Supabase-specific caveat that
makes the naive command dangerous on a hosted project. This article is the
reset path I use, with the gotchas inline.

The original Stack Overflow thread ("How can I drop all the tables in a
PostgreSQL database?") has been viewed more than 1.5 million times for a
reason: every developer hits this during a migration at least once.

The one-command reset

-- ⚠️  Destructive. Drops every table, view, sequence, and function in public.
DROP SCHEMA public CASCADE;
CREATE SCHEMA public;
GRANT ALL ON SCHEMA public TO postgres;
GRANT ALL ON SCHEMA public TO public;

DROP SCHEMA public CASCADE removes the public schema and every object that
depends on it — tables, views, materialized views, sequences, functions, and
triggers. CASCADE is what saves you from listing the dependencies in order.
Then you recreate the empty schema and restore the default grants.

That second GRANT ... TO public line is where the PostgreSQL 15 gotcha lives.

The PostgreSQL 15 gotcha that breaks this

PostgreSQL 15 changed two defaults on the public schema, and both of them
bite you when you drop and recreate it:

PUBLIC no longer has CREATE on public by default. Before 15, every role could create objects in public. From 15 onward, on new databases and new clusters, that privilege is revoked. This is the secure-schema pattern PostgreSQL has recommended since CVE-2018-1058, now made the default.
The owner of public is now pg_database_owner, not the bootstrap superuser. This lets database owners manage public without being a superuser.

When you run CREATE SCHEMA public on a 15+ database, the schema comes back
with these new secure defaults. Your application role — the one that runs
INSERT, CREATE TABLE, migrations — no longer has CREATE on public. The
next migration or insert throws:

ERROR: permission denied for schema public

If you already hit that, the fix is to grant explicitly to the role your app
actually uses, instead of relying on PUBLIC:

CREATE SCHEMA public;
GRANT USAGE ON SCHEMA public TO app_role;
GRANT CREATE  ON SCHEMA public TO app_role;

On Supabase, the anon and authenticated roles also need USAGE on public or
your client queries fail with the same error. For a deeper write-up of that
specific failure, see Supabase client "permission denied for schema public"
fix.

The variant that keeps extensions

DROP SCHEMA public CASCADE also drops every extension installed in the
public schema. uuid-ossp, pgcrypto, pg_stat_statements (if installed
there), and — critically on Supabase — pgvector all live somewhere. If you
rely on gen_random_uuid(), uuid_generate_v4(), or vector columns, they
vanish and you get:

ERROR: function gen_random_uuid() does not exist

Reinstall them after recreating the schema:

CREATE SCHEMA public;
GRANT ALL ON SCHEMA public TO postgres;

-- Reinstall the extensions you actually use.
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS pgcrypto;
CREATE EXTENSION IF NOT EXISTS vector;   -- pgvector

If you never want to lose extensions during a reset, drop the tables only and
leave the schema (and its extensions) intact — see the selective script below.

Drop only tables, keep everything else

When extensions and functions must survive the reset, drop tables individually
via information_schema instead of nuking the whole schema:

DO $$
DECLARE
  r RECORD;
BEGIN
  FOR r IN
    SELECT tablename FROM pg_tables
    WHERE schemaname = 'public'
  LOOP
    EXECUTE 'DROP TABLE IF EXISTS public.' || quote_ident(r.tablename) || ' CASCADE';
  END LOOP;
END $$;

This loops over every table in public and drops it with CASCADE (so views
and foreign keys depending on it go too). Functions, sequences created by
SERIAL columns (they get dropped with their tables), and extensions stay.

To also reset sequences after reloading data:

SELECT setval(pg_get_serial_sequence('public.' || quote_ident(t.tablename), 'id'),
              1, false)
FROM pg_tables t
WHERE schemaname = 'public';

The Supabase path: do not run DROP SCHEMA on production

On a hosted Supabase project, public is not the only schema that matters. The
auth, storage, realtime, and graphql schemas are all managed by Supabase
and reference objects that your tables depend on. Running
DROP SCHEMA public CASCADE on a production project can cascade into Supabase's
internal objects and break the dashboard, auth, and storage.

For a dev project, use the controlled reset:

# CLI: drops and rebuilds everything from your migrations folder
supabase db reset

Or in the dashboard: Project Settings → Database → Reset database. Both
rebuild the schema from your migration files, which is the safe path — your
schema is reproducible from code, not from memory.

For production, never reset. Restore from a backup or a pg_dump snapshot:

pg_dump "$DATABASE_URL" -F c -f backup.dump
# ... later, to restore:
pg_restore -d "$DATABASE_URL" -c backup.dump

If the reset is part of a failed migration, follow the
PostgreSQL migration rollback playbook
instead of dropping tables by hand.

The transaction wrapper for dev

On a local database, wrap the reset in a transaction so a typo does not leave
you in a half-dropped state:

BEGIN;
DROP SCHEMA public CASCADE;
CREATE SCHEMA public;
GRANT ALL ON SCHEMA public TO postgres;
-- sanity check: SELECT 1;
COMMIT;
-- if something looked wrong: ROLLBACK; (but the schema is already gone)

Note: DROP/CREATE SCHEMA inside a transaction is safe to ROLLBACK —
PostgreSQL transactional DDL means a rollback restores the dropped schema. This
is one of the features that makes Postgres migrations far less scary than other
engines.

Production safety checklist

Before you run any of this against anything that is not a throwaway dev
database:

Take a backup first. pg_dump -F c is cheap insurance.
Confirm the connection string. \conninfo in psql — verify you are not pointed at prod. The number of times a reset has hit the wrong database is exactly why this section exists.
Block new connections during the reset if other services share the DB: ALTER DATABASE yourdb CONNECTION LIMIT 0; then terminate backends, reset, then restore the limit.
Have a tested restore path. A backup you have never restored from is a wish, not a backup.

For the broader posture — when to roll forward vs roll back, how to stage
migrations so a reset is never the plan — read the
database design and optimization guide.

Common mistakes

Forgetting CASCADE. Without it, DROP SCHEMA refuses to run if any object exists in it. CASCADE is the whole point.
Running it in the wrong database. Use SELECT current_database(); to confirm before you press enter. \l lists databases.
Not re-granting on PostgreSQL 15+. The schema recreates with secure defaults and your app role loses CREATE. See the gotcha section above.
Dropping on a hosted Supabase prod. Use supabase db reset on dev only.
Dropping extensions by accident. Reinstall uuid-ossp, pgcrypto, pgvector after CREATE SCHEMA, or use the table-only loop.

When you should not do this at all

A full reset is a dev convenience. In production, "drop everything and start
over" is almost always the wrong instinct. The right move is usually a targeted
migration: ALTER TABLE, a backfill, a column drop behind a feature flag. If
you are resetting because a migration is too tangled to untangle, the fix is
to write smaller, reversible migrations going forward — not to make resetting
easier.

The RLS debugging guide covers the same
instinct for policy drift: most "blow it away" urges are really "I cannot see
what changed" problems.

TL;DR

-- Dev reset, PostgreSQL 15+:
DROP SCHEMA public CASCADE;
CREATE SCHEMA public;
GRANT ALL ON SCHEMA public TO postgres;
GRANT USAGE, CREATE ON SCHEMA public TO app_role;  -- re-grant your app role
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";        -- restore extensions
CREATE EXTENSION IF NOT EXISTS pgcrypto;

On Supabase dev: supabase db reset. On Supabase prod: restore from a backup,
do not drop the schema.

Originally published at https://www.iloveblogs.blog

Next.js useSearchParams Suspense: Static Rendering Fix 2026

Mahdi BEN RHOUMA — Fri, 21 Aug 2026 14:31:53 +0000

I hit the build error useSearchParams() should be wrapped in a suspense boundary at page "/" for the first time while shipping a Supabase-backed filter UI in Next.js 15, and the fix was a one-line wrap: put the component that calls useSearchParams inside a <Suspense> boundary, and the rest of the page prerenders normally. This guide covers the exact pattern, the real reason the build refuses to ship without a boundary, and a verification step that proves the route stayed in the static output. I also link to the longer-form version of this fix in Missing Suspense Boundary with useSearchParams (Next.js) and to the broader query-reading primer in How to get query string parameters in Next.js.

Shortcut: the free Next.js Build Error Decoder recognizes this exact prerender error — paste your build output and jump straight to the matching fix.

The exact error and when it fires

The error you see in your terminal during next build looks like this:

$ npx next build

   ▲ Next.js 15.0.0

Error: useSearchParams() should be wrapped in a suspense boundary at page "/products".

Read more: https://nextjs.org/docs/messages/missing-suspense-with-csr-bailout

It fires when three things are true at the same time. First, a Client Component — a file with the "use client" directive at the top — calls the useSearchParams hook from next/navigation. Second, that Client Component is being prerendered, which is the default in the App Router for any route that does not opt out. Third, there is no <Suspense> boundary above the call in the rendered tree. When all three conditions are met, Next.js refuses to fall back to dynamic rendering silently and instead throws, because silently bailing out would hide a real problem: the prerendered HTML would either be wrong or empty.

The same error appears in the browser console in dev mode when you navigate to the page directly, and it appears in your CI logs the moment you run next build against a route that violates the invariant. The official documentation page that the error links to is https://nextjs.org/docs/messages/missing-suspense-with-csr-bailout, and that page is the only place I trust for the canonical wording — the message has been stable across the 15.x line.

Why Next.js refuses to statically render useSearchParams

The hook reads the current URL's query string. At build time there is no browser and no URL — there is only a render function being asked to produce HTML for a route that may eventually be visited with any query string at all. Next.js handles this with a two-phase strategy. During prerender it renders a static shell, and during client hydration the URL is read and the actual UI is filled in. The mechanism that lets that two-phase render happen is <Suspense>: the boundary tells the prerender pass "you can stop here, emit a fallback, and let the rest resolve on the client."

Without a <Suspense> boundary above the call, the prerender pass has no instruction for how to stop. It would have to either invent a value for the search params (which would be wrong) or refuse to prerender the page at all. Next.js chooses the second option, which is why the build fails loudly rather than shipping a broken page. The same mechanism is what lets a Server Component fetch data and a Client Component read the URL in the same tree, as long as the Client Component is wrapped.

The reason this matters beyond just copying the fix is that the same invariant shows up in other forms. If you ever hit Dynamic Server Usage: couldn't be rendered statically because it used cookies or headers, that is the same boundary idea, and the fix is structurally identical — narrow the dynamic read to the smallest possible client subtree. I unpack that case in Fix Dynamic Server Usage Error in Next.js App Router.

The fix: split the page and wrap the reads in a Suspense boundary

The minimal change is to take any file that has "use client" at the top and calls useSearchParams, and refactor it so the page itself is a Server Component shell that hands the search-reading work to a child Client Component inside <Suspense>. The Server Component renders the static output, the Suspense boundary is the marker that tells the prerender pass where to stop, and the child Client Component hydrates on the client with the real URL.

Here is the broken version that throws during build. Do not ship it:

// app/(shop)/products/page.tsx
// ❌ Throws "useSearchParams() should be wrapped in a suspense boundary".
"use client";

import { useSearchParams } from "next/navigation";

export default function ProductsPage() {
  const sp = useSearchParams();
  const category = sp.get("category") ?? "all";

  return (
    <main>
      <h1>Products</h1>
      <p>Filtering by: {category}</p>
    </main>
  );
}

And here is the fix. The page becomes a Server Component, the search-reading logic moves to a child file marked "use client", and that child is rendered inside a <Suspense> boundary with a sensible fallback:

// app/(shop)/products/page.tsx
// ✅ Server Component shell. Renders to the static output at build time.
import { Suspense } from "react";
import ProductsFilter from "./products-filter";

export const metadata = {
  title: "Products",
};

export default function ProductsPage() {
  return (
    <main>
      <h1>Products</h1>
      <Suspense fallback={<p>Loading filters…</p>}>
        <ProductsFilter />
      </Suspense>
    </main>
  );
}

// app/(shop)/products/products-filter.tsx
// ✅ Client Component. Called inside a <Suspense> boundary, so the
// prerender pass can emit the fallback and hydrate on the client.
"use client";

import { useSearchParams } from "next/navigation";

export default function ProductsFilter() {
  const sp = useSearchParams();
  const category = sp.get("category") ?? "all";

  return <p>Filtering by: {category}</p>;
}

Two things stand out about this diff. First, the page.tsx no longer has "use client", so it runs on the server and gets the full Server Component benefits — metadata exports work, server-only imports work, and the route is eligible for static prerendering. Second, the fallback you pass to <Suspense> is what actually ships in the static HTML, so it should be a real loading state, not an empty fragment. A short paragraph or skeleton is usually enough.

Step-by-step: ship it without losing the static shell

Find every file in your app/ tree that calls useSearchParams from next/navigation. Grep for it with rg "useSearchParams" app components to get a list in one shot.
For each one, check whether the file has "use client" at the top. If the page itself is a Client Component, decide whether it really needs to be — most pages do not.
Refactor the file so the page exports a Server Component, and the search-reading logic moves to a sibling Client Component. The Server Component imports the child and renders it inside <Suspense fallback={...}>.
If the child component was previously exported as the default of a page file, rename it to something like *-view.tsx or *-filter.tsx and update the import in page.tsx.
Re-run next build and confirm the offending route shows the ○ marker in the route table, which means it was prerendered. If the marker is λ, the Suspense boundary is not doing its job and the route is still dynamic.

Verify the route stayed static

The fastest way to confirm the fix is to read the route table that next build prints. Run a clean production build and look for the marker next to your route:

# 1. Clean any stale build output so the route table is fresh.
rm -rf .next

# 2. Run the production build and capture the full route table.
npx next build

# 3. Look for the route marker. ○ = static, λ = dynamic, ƒ = function.

The output you want looks like this. The ○ (hollow circle) marker is the indicator that the route was prerendered at build time:

Route (app)                                Size     First Load JS
┌ ƒ /api/products                          0 B            0 B
├ ○ /                                      123 B          82 kB
├ ○ /products                              1.4 kB         89 kB
└ ○ /_not-found                            871 B          82 kB

If you see λ (lambda) instead of ○ next to /products, the route is being treated as dynamic, which usually means a Server Component somewhere in the tree is reading searchParams, cookies(), or headers(). The <Suspense> boundary does not rescue that case — it only helps when the reads are confined to a Client Component subtree. If your build still shows λ after the refactor, walk the tree again and check for stray cookies() or headers() calls.

A second useful check is the prerendered HTML itself. Inspect the page source after deployment and confirm the Suspense fallback is in the static output, not the search-reading markup. The fallback is what search engines and link-preview bots see, so it should be a sensible message rather than an empty fragment.

Two patterns that still trip you up

The whole page is "use client". This is the most common cause I see in code reviews. A developer adds "use client" to a page file because they need one tiny bit of interactivity, and the whole page becomes a Client Component. The fix still works inside the same file — you can wrap the search-reading JSX in <Suspense> directly — but you lose Server Component benefits for that route, including the metadata export, server-only imports, and the ability to call Supabase from the page itself. If the page is on a Supabase stack and the page itself should be able to fetch from the database, split it. The page becomes a Server Component, the search-reading JSX moves to a child file marked "use client", and the rest works as in the diff above.

The <Suspense> boundary is below the useSearchParams call. Boundaries do not work retroactively. If your tree is <ProductsPage> (Client Component, calls useSearchParams) → <Suspense> → <Child>, the prerender pass has already hit the hook before it sees the boundary, and you still get the build error. The boundary has to be above the call, which usually means the hook and the boundary live in the same Client Component subtree, or the page itself is the boundary's parent.

A related case is reading searchParams in a Server Component, which does not require <Suspense> at all. The searchParams prop on a Server Component page is fully resolved at request time, and the page is then marked dynamic. That is a different problem from this one — I cover it separately in How to get query string parameters in Next.js — but the two errors often get conflated, so it pays to be clear about which one you are actually hitting.

Why this happens and how to keep it from coming back

The underlying invariant is simple: any Client Component that reads runtime browser state (URL, window, localStorage) must live inside a boundary that the prerender pass knows how to stop at. <Suspense> is that boundary, and the hook contract on useSearchParams is that the caller guarantees one is present. There is no point in trying to read useSearchParams outside a boundary — the hook has no way to return a value during prerender, so the only correct options are the boundary or making the route dynamic.

The cheapest way to keep this from regressing is to add a build step to CI that runs next build and fails the pipeline on this specific error string. I have a short script for this in Next.js + Supabase CI/CD Pipelines with GitHub Actions, and the same pattern works whether the destination is Vercel, Fly, or a plain Node server. The other half of prevention is the file-level rule of thumb: if a file in app/ calls useSearchParams, the file that imports it must be a Server Component that wraps the import in <Suspense>. Code review catches this fast, and rg "useSearchParams" app should be a routine command in your day-to-day work.

If your stack ships to production behind a build step — and on a Next.js + Supabase project it should, because the static output is what makes the edge fast — make this rule a checklist item in the deployment guide. I keep the production checklist in Deploying Next.js + Supabase to Production, and the Suspense invariant is one of the items I check before a green build.

FAQ

What does "useSearchParams() should be wrapped in a suspense boundary" mean in plain English? It means a Client Component in your tree is reading the URL during a render that Next.js is trying to prerender, and there is no <Suspense> boundary above the call to tell the prerender pass where to stop. Add the boundary, with a fallback, and the route can ship as a static page.

Can I just make the route dynamic and skip the Suspense boundary? Yes. Adding export const dynamic = "force-dynamic" to the page, or reading searchParams in a Server Component, both turn off static prerendering for that route. The trade-off is real: you lose the static cache and the page renders on every request. Wrap the reads in <Suspense> if you can; fall back to dynamic only if the page genuinely cannot be split.

Does the Suspense fallback hurt SEO or accessibility? No. The fallback is what ships in the static HTML, and search engines index the static HTML. The search-reading subtree hydrates on the client and replaces the fallback with the real content. Make the fallback descriptive — "Loading filters…" is fine — and you do not lose anything.

I added Suspense and the build still throws. What now? Walk the tree above the failing call. The boundary must be a parent of the component that calls the hook, not a sibling or a child. If the page itself is "use client", the boundary inside the same file works but you lose Server Component benefits — split the file. If the page is a Server Component, the boundary must wrap the child that calls the hook, not the page.

Is there a way to read the query string without a Client Component at all? Yes. In the App Router, a Server Component page receives searchParams as a prop. That prop is fully resolved at request time, so the page becomes dynamic, but you do not need useSearchParams and you do not need <Suspense>. Use the prop when the whole page is request-dependent; use useSearchParams inside <Suspense> when only a small subtree is.

Originally published at https://www.iloveblogs.blog

Sign In to Supabase Without Email Verification (2026)

Mahdi BEN RHOUMA — Fri, 21 Aug 2026 14:31:47 +0000

The friction

You are building locally. You sign up a test user, Supabase replies
"Check your email to confirm your account", and now you have to open the
inbox, click the link, and only then can you log in. Every. Single. Iteration.

On hosted Supabase, email confirmation is on by default. On self-hosted
and local (supabase start) it is off by default. So the friction is worst
when you are developing against a hosted project — which is most people.

The original ask for this is supabase/supabase#5113:
a flag to let users sign in without email confirmation. The flag exists in
three forms, depending on whether you want to disable it globally or just
confirm one user.

Option 1 — Turn it off in the dashboard (hosted dev)

Dashboard → Authentication → Sign In / Providers → Email → Confirm email:
OFF

URL: https://supabase.com/dashboard/project/_/auth/providers

New signups can now sign in immediately. No confirmation email is sent.

This is project-wide. It affects every signup on that project, so use it
only on a dev project, not production.

Option 2 — Turn it off in config (self-hosted / local)

In supabase/config.toml:

[auth.email]
enable_confirmations = false

Restart the auth container:

supabase stop && supabase start

Self-hosted and local projects ship with enable_confirmations = false, so
you only need this if you previously turned it on.

Option 3 — Confirm one user with the admin API (production-safe)

When you want to keep confirmation on globally but pre-confirm one user — a
team member, an invited customer, a test account — use the admin API with the
service role key:

// server-only — NEVER expose the service role key to the browser
import { createClient } from '@supabase/supabase-js'

const supabaseAdmin = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!, // service role, not anon
)

const { data, error } = await supabaseAdmin.auth.admin.createUser({
  email: 'teammate@example.com',
  password: 'a-strong-temporary-password',
  email_confirm: true, // ✅ user is already confirmed, no email sent
})

email_confirm: true writes email_confirmed_at for you. The user can sign
in immediately. This is the right tool for production invites.

Option 4 — Confirm an existing user in SQL

For a user who already exists but is stuck unconfirmed:

update auth.users
set email_confirmed_at = now(),
    confirmed_at = now()
where email = 'teammate@example.com';

Run this in the SQL editor with the service role. It is the surgical option —
no setting changes, no API call, just flip the column. Useful when a
confirmation email bounced or a user lost access to their inbox.

⚠️ Do not expose this as a client-callable function. Anyone who can run it
against auth.users can confirm any email — which is account takeover. It
is a server-side escape hatch, not a feature.

When you must keep confirmation on

In production, keep email confirmation on. Three reasons:

Account takeover. Without confirmation, anyone can sign up with an email they do not own and lock the real owner out of that address on your app.
Spam signups. Bots fill your auth.users table with garbage, which costs you rows and skews analytics.
Abuse of free tier. Unverified signups are the main vector for Supabase free-tier quota abuse; a project with confirmation off is a magnet for it.

The production pattern: confirmation on, plus the admin API for pre-
confirmed invites. Disable confirmation only on dev and staging projects.

The redirect after sign-in

Once confirmation is off (or the user is confirmed), the next friction is
where they land after signInWithPassword. If the post-login redirect is
broken, the user is authenticated but staring at the wrong page — see
fix Supabase auth redirects that land on the wrong URL.
And if the session itself does not persist across refreshes, it is the
Supabase auth session persistence
issue, not email confirmation.

Common mistakes

Disabling confirmation in production. It is a security control, not a convenience. Use the admin API to pre-confirm individuals instead.
Using the service role key in the browser. The service role bypasses RLS. If it ships in client code, your database is public. The getSession() security warning covers the same boundary from the read side.
Forgetting the OAuth path still verifies. Turning off email confirmation does not affect OAuth providers — Google, GitHub already verify the email upstream, so email_confirmed_at is set on the OAuth callback regardless.
Treating confirmed_at and email_confirmed_at as different. Set both in SQL; Supabase reads both depending on the flow.

TL;DR

Hosted dev: dashboard → Auth Providers → Email → Confirm email OFF.
Local/self-hosted: auth.email.enable_confirmations = false in config.toml.
Production: keep it ON. Pre-confirm individuals with the admin API (email_confirm: true) or SQL (update auth.users set email_confirmed_at = now()).

Originally published at https://www.iloveblogs.blog

Supabase "Database Error Saving New User" Trigger Fix

Mahdi BEN RHOUMA — Fri, 21 Aug 2026 14:31:04 +0000

The error

You add a trigger to copy new auth users into a public.users (or
public.profiles) table. The first signup after that throws a vague error on
the client:

Database error saving new user

No user row in auth.users. No row in public.users. The signup is dead. The
message is intentionally generic — Supabase hides the underlying Postgres
error from the client — but the cause is almost always the same: your
trigger threw, and the transaction rolled back the auth insert with it.

This is the exact scenario in supabase/supabase#563:
an AFTER INSERT trigger on auth.users copies the row into public.users,
the copy fails for a constraint or permission reason, and the exception kills
the signup.

The reproduction

The trigger from that issue, lightly cleaned up:

create or replace function public.signup_copy_to_users()
returns trigger
language plpgsql
security definer
as $$
begin
  insert into public.users (id, email)
  values (new.id, new.email);
  return new;
end;
$$;

create trigger signup_copy
  after insert on auth.users
  for each row execute function public.signup_copy_to_users();

This looks fine. It is not. Three things go wrong with it in production:

AFTER INSERT runs in the same transaction. Any exception in the body rolls back the auth.users insert. Signup dies.
SECURITY DEFINER with no search_path. This is the CVE-2018-1058 search-path hijacking pattern. A hostile user with CREATE on public could shadow public.users with a malicious function. Postgres 15 made CREATE on public non-default (see Supabase "permission denied for schema public" fix), but you still pin search_path.
No error handling. A single bad row — a NULL on a NOT NULL column, a duplicate email, an RLS denial — breaks every signup until you fix it.

The fix

Two changes: pin the search path, and make the profile copy non-fatal.

create or replace function public.handle_new_user()
returns trigger
language plpgsql
security definer
set search_path = public          -- ✅ pin search_path, block hijacking
as $$
begin
  insert into public.users (id, email, created_at)
  values (new.id, new.email, now());

  return new;

exception
  when others then
    -- ✅ log the failure but do NOT roll back auth.users
    raise log 'handle_new_user failed for %: %', new.id, sqlerrm;
    return new;
end;
$$;

-- Replace the old trigger
drop trigger if exists signup_copy on auth.users;
drop trigger if exists on_auth_user_created on auth.users;

create trigger on_auth_user_created
  after insert on auth.users
  for each row execute function public.handle_new_user();

The two edits that matter:

set search_path = public on a SECURITY DEFINER function is now required best practice. Without it, the function resolves unqualified names against the caller's search_path, which an attacker can manipulate.
exception when others then return new decouples the profile copy from the auth insert. A failed copy logs the error and lets the signup proceed. The user can sign in; you fix the orphaned profile later from the log.

You can route the log to Supabase's log explorer or a public.signup_errors
table if you want to drive a backfill job from it.

Why SECURITY DEFINER at all

Without SECURITY DEFINER, the trigger runs as auth.users's owner on the
auth schema but inserts into public.users as whoever the caller is. If
public.users has RLS, the anon role may have no INSERT policy, and the
copy fails — rolling back the signup. SECURITY DEFINER runs the function as
its owner (typically the migrations role, which bypasses RLS), so the insert
goes through.

That is the same reason the getSession() security warning exists: relying on
the wrong privilege boundary. The rule for auth triggers:

SECURITY DEFINER so RLS on public.users cannot block the copy.
SET search_path = public so the definer cannot be hijacked.
exception when others so a copy failure cannot kill a signup.

For the matching server-side rule on reads, see
stop the Supabase getSession() security warning.

The RLS angle

Debugging a policy instead of a trigger? The free Supabase RLS Policy Debugger matches the common failure signatures (WITH CHECK, recursion, GRANTs) and returns the corrected SQL.

If public.users has RLS, the handle_new_user insert runs as the function
owner, not the new user. That is usually what you want — the new user has no
row yet, so a policy like using (id = auth.uid()) would block the very insert
that creates their row. Keep SECURITY DEFINER so the trigger can seed the
row, then let RLS govern subsequent access.

A common misconfiguration: a WITH CHECK (id = auth.uid()) policy on
public.users that works for updates but makes the initial insert depend on
auth.uid() resolving before the user exists. The trigger runs after the
auth.users insert, so auth.uid() is valid — but if you accidentally run
the insert as anon instead of via SECURITY DEFINER, it fails. The
Supabase RLS debugging guide covers
the auth.uid() resolution order in depth.

Check the target table first

Before blaming the trigger, confirm the target table is insert-able in
isolation:

-- As the migrations role, not anon:
insert into public.users (id, email)
values ('00000000-0000-0000-0000-000000000000', 'test@example.com');

If that fails, the trigger is not your problem — the table is. Common causes:

A NOT NULL column without a default that the trigger does not populate.
A unique constraint on a column you are not setting.
A foreign key to a row that does not exist.
A column type mismatch (e.g. text vs uuid on id).

Fix the table, then the trigger stops throwing.

Production recommendations

Deploy the trigger, then test signup immediately with a throwaway email. A broken trigger breaks every signup, so verify before you walk away.
Do not run DDL that recreates the trigger during a signup burst. The drop trigger / create trigger pair has a tiny window where inserts have no trigger; that is usually fine, but it does not need to be in your hot path.
Log exceptions to a table you monitor, not just raise log. The log explorer is easy to miss; a signup_errors table with a Slack nudge is not.
Pin search_path on every SECURITY DEFINER function, not just this one. It is the cheapest security win in Supabase. The Supabase security best practices guide treats this as a baseline.

TL;DR

create or replace function public.handle_new_user()
returns trigger
language plpgsql
security definer
set search_path = public
as $$
begin
  insert into public.users (id, email, created_at)
  values (new.id, new.email, now());
  return new;
exception
  when others then
    raise log 'handle_new_user %: %', new.id, sqlerrm;
    return new;   -- never let the copy roll back auth.users
end;
$$;

create trigger on_auth_user_created
  after insert on auth.users
  for each row execute function public.handle_new_user();

Three things: pin the search path, use SECURITY DEFINER so RLS cannot block
the seed insert, and swallow exceptions so a copy failure never breaks a signup.

Originally published at https://www.iloveblogs.blog

Next.js "Server Is Running Out of Memory" Fix (2026)

Mahdi BEN RHOUMA — Fri, 21 Aug 2026 14:30:58 +0000

Shortcut: paste your failing output into the free Next.js Build Error Decoder — it recognizes the heap-out-of-memory signature (and 12 others) and links straight to the fix that applies.

The message

You are running next dev (or a Node production server), the terminal prints
this, and the server restarts:

The server is running out of memory, restarting to free up memory

Routes reload slowly, sessions drop, and in dev your HMR stops working for a
few seconds every time it fires. This was filed as
vercel/next.js#46756 (dev
App Router + RSC accumulation) and tracked as NEXT-1353, with the production
side in vercel/next.js#49929
(NEXT-1314, high memory in deployed projects).

The message is a symptom, not a diagnosis. Next.js notices the Node heap
crossed its limit and restarts to recover. Your job is to find out why it
crossed — and there are only three possible buckets.

The three causes

Dev-mode accumulation — the classic App Router + RSC hot-reload leak in Next.js 13.x. Repeated refreshes grow the heap until it restarts. This is a tooling problem, not your code.
A real leak in your app or deps — an in-memory cache without eviction, event listeners never removed, a closure holding a growing dataset, a Map that never gets pruned.
A legitimate heap that is too big for the limit — a route that loads a large dataset into memory at build time, a heavy getStaticProps / generateStaticParams job, or sourcemaps in production.

You diagnose by bucket. The fixes are different.

First, stop the restarts (band-aid)

Raise the V8 heap limit so you can actually work while you investigate:

# 4 GB heap (dev)
NODE_OPTIONS=--max-old-space-size=4096 npm run dev

# 8 GB heap (large production builds)
NODE_OPTIONS=--max-old-space-size=8192 npm run build

This is not a fix. It is the room you need to take a heap snapshot instead of
getting restarted out of the inspector. Set it, then move to diagnosis.

If it only happens in dev — switch to Turbopack

The 13.x dev-mode leak in webpack's App Router pipeline is the single most
common cause of this message. If you are on Next.js 14+ and still hitting it
in dev, try Turbopack first:

next dev --turbo

Turbopack's module graph does not accumulate on hot reload the way webpack
did, so for the classic dev leak it resolves immediately. This is the lowest-
effort, highest-hit fix in this whole article.

If you are on an older 13.x and cannot move to Turbopack, upgrade to the
latest stable — the dev accumulation was steadily reduced across 13.x and
largely resolved in 14+. Do not stay on a leaking canary.

Diagnose a real leak with a heap snapshot

If Turbopack did not help, or the leak is in production, take a heap snapshot.
Run the dev server under the inspector:

NODE_OPTIONS='--inspect' npm run dev
# or for a production Node server:
NODE_OPTIONS='--inspect' node server.js

Open chrome://inspect → inspect → Memory tab → Heap snapshot.
Use the three-snapshot technique:

Snapshot A — after the app warms up.
Snapshot B — after running the leaking flow once.
Snapshot C — after running it again.

In the comparison view (C vs B vs A), objects that grow between every snapshot
are your leak. Filter to "retained size" and look for your own domain objects
(users, rows, requests) — if you see your own types growing, the leak is in
your code. If you only see framework / node internals, the leak is upstream
(or you are holding references to your data in a structure you forgot about).

In server.js, log the heap on an interval to catch growth across requests:

// server.js (or a small instrumentation file)
setInterval(() => {
  const m = process.memoryUsage();
  console.log(
    `rss=${(m.rss / 1048576).toFixed(0)}MB ` +
    `heapUsed=${(m.heapUsed / 1048576).toFixed(0)}MB ` +
    `heapTotal=${(m.heapTotal / 1048576).toFixed(0)}MB ` +
    `external=${(m.external / 1048576).toFixed(0)}MB`,
  );
}, 10_000);

A flat line means no leak. A steady climb that never settles means a leak.

Common app-level leaks

The usual suspects, in order of how often I have seen them:

Module-level Map / Set / array caches. A const cache = new Map() at module scope that you write to on every request and never evict from. Fix: bound it (an LRU), move it to a real cache (Redis / KV), or recompute.
Event listeners never removed. A setInterval or an event emitter you attach on every request and never removeListener / clearInterval. Each request leaks the listener and everything it closes over.
Closures holding large datasets. A request handler that builds a giant array inside a closure passed to a long-lived callback. The array lives as long as the callback does.
Sourcemaps in production. productionBrowserSourceMaps: true or a misconfigured build keeps large source content in memory. Disable for the Node server, keep them only for client error reporting.
Heavy generateStaticParams / build-time fetches. Pulling a large dataset into memory at build time to enumerate pages. Stream it from disk or a DB cursor instead.

Production levers

For deployed Next.js (Node server or serverless), memory is a resource you
budget for. The levers, biggest first:

Move large in-memory caches out of the process. Anything that grows with traffic belongs in Redis, Upstash, or your platform's KV, not in a Map. This is the single largest production win.
Stream large responses. Do not await an entire dataset into memory then JSON.stringify it. Stream it. Response with a ReadableStream, or the streaming render APIs, keep the working set small.
Prune dependencies. next build shows the largest server modules. A heavy dep loaded into the server bundle sits in memory for the life of the process. Lazy-import the rare ones with await import().
Disable sourcemaps on the server. They are for dev and error reporting; shipping them on the server inflates resident memory.
Raise the serverless memory budget. On Vercel, serverless functions have a per-function memory ceiling (1 GB on Hobby, more on Pro — confirm on your plan). A route that genuinely needs more memory should be split out and given its own configuration rather than dragging the whole app up.
Use the Edge Runtime for stateless routes. Edge functions have a smaller, fixed memory profile and no Node heap growth; move the routes that are pure request/response work over. For the gotchas of what you cannot run on Edge (no native TCP, no sync FS), the dynamic server usage / could not be rendered statically fix covers the boundary.

The dev-vs-prod split

A leak that only reproduces in next dev and never in next build / next start is almost always the webpack dev pipeline. Do not spend two days
hunting a leak in your code that is actually webpack's hot-reload graph —
try Turbopack for thirty seconds first.

A leak that reproduces in next start against a production build is your
code or your deps. Take the three-snapshot path above.

And the failure mode that is not a leak at all: the build passes locally, you
deploy, and it breaks in production for a different reason. That is the
build passes locally, broken in production
postmortem, not this one. They look similar from the outside and have
completely different causes.

Production checklist

[ ] NODE_OPTIONS=--max-old-space-size set for the build and the server.
[ ] No module-level unbounded caches; every cache has an eviction policy or lives outside the process.
[ ] No setInterval / listeners without a matching teardown.
[ ] Sourcemaps disabled on the Node server.
[ ] Large routes streamed, not buffered.
[ ] Heavy routes split out with their own memory budget if on serverless.
[ ] Stateless routes on Edge where possible.
[ ] An alert on process.memoryUsage().heapUsed so you see growth before the restart message does.

For the broader performance posture — what to measure, what to move to Edge,
how to keep the bundle thin — the
Next.js performance optimization guide
is the longer read. For the deploy-time failure modes that look like memory
issues but are not (middleware not running, static assets 404), see
middleware not running in Vercel production
and the deploying Next.js + Supabase to production
guide.

TL;DR

Restarting on memory? Raise the heap with NODE_OPTIONS=--max-old-space-size=4096 to stop the bleeding.
Only in dev? Switch to next dev --turbo — the classic 13.x webpack leak is the most common cause and Turbopack sidesteps it.
In production? Take three heap snapshots, find what grows, move caches out of the process, stream large responses, disable server sourcemaps.

Originally published at https://www.iloveblogs.blog

Fix Next.js 'Cannot Have a Negative Time Stamp' Error

Mahdi BEN RHOUMA — Sun, 16 Aug 2026 08:03:09 +0000

You refresh a page on your Turbopack dev server — usually one that just called notFound() — and the dev overlay slams this in your face:

Unhandled Runtime Error

Failed to execute 'measure' on 'Performance':
'NotFound' cannot have a negative time stamp.

The quoted component name varies: 'NotFound', 'Page', 'SlugPage' for a [slug]/page.tsx route, or 'AdministrationPage [Prerender]' behind an auth guard. On Firefox the wording differs — Performance.measure: Given attribute end cannot be negative — but it is the same failure. The stack trace points into react-server-dom-turbopack-client.browser.development.js, and the error appears only in next dev with Turbopack. Your production build is fine.

The bug is tracked upstream in vercel/next.js issue #86060, first reported against Next.js 16.0.2-canary with React 19.2.0 and reproduced by commenters on stable 16.1.1 and 16.1.6. It is still open as of August 2026. Below are the triggers in descending order of how often they show up in that thread, each with a confirmation test and a fix.

Cause 1: notFound() on a dynamic or catch-all route

This is the original report and the most common trigger. React's development-only performance track initialises an internal childrenEndTime variable to -Infinity. When notFound() interrupts rendering before any children are processed, that variable is never updated — and React then calls performance.measure() with the still-negative value. The happy path guards against this (0 <= childrenEndTime); the abort and rejection paths do not, which is exactly what PR #88688 identified.

Confirm it: hit a URL that does not exist under a dynamic segment — /blog/does-not-exist for a [slug] route with notFound() in it. If the overlay error names your route's component ('SlugPage', 'NotFound'), this is your cause. One commenter noted the error is intermittent but becomes near-certain after editing not-found.tsx and refreshing a few times — HMR makes the race more likely.

Fix: a commenter on the issue resolved it by moving not-found.tsx out of the dynamic route folder into its parent directory. The catch-all still resolves the 404 correctly (Next.js walks up the tree for the nearest not-found file), but the render-abort no longer happens inside the segment whose timing React is measuring. If restructuring is not an option, jump to the workarounds section.

Cause 2: redirect() in a Server Component

The second cluster of reports involves redirect() rather than notFound() — typically auth or admin guards that redirect before the page finishes rendering:

// app/[locale]/admin/page.tsx
export default async function AdministrationPage() {
  const session = await getSession()
  if (!session?.user?.isAdmin) {
    redirect('/login') // ← interrupts the render mid-measurement
  }
  return <AdminDashboard />
}

The mechanism is the same: a server-side redirect completes before the component's performance measurement window closes, so the computed duration goes negative. A February 2026 comment on the issue pinned the throwing call to the flushComponentPerformance function at line 3776 of the Turbopack development bundle.

Confirm it: the error names the guarded page (often with a [Prerender] suffix) and fires on the initial load of a route that conditionally redirects — not on a 404.

Fix: there is no code-level fix on your side that keeps the redirect logic intact; the guard is correct, React's dev instrumentation is not. Use one of the workarounds below. Do not move the redirect into a useEffect just to silence a dev-only overlay — that would ship a real flash-of-content regression to users to hide a cosmetic error.

Cause 3: next/dynamic with ssr: false on an older React

An earlier variant of the same error came from next/dynamic components with { ssr: false } inside client components. There, a fiber that never completed its work phase kept its initial startTime of -1.1, and React's logComponentMount fed that into performance.measure(). React fixed this one upstream in facebook/react PR #32823, merged in April 2025.

Confirm it: you are on a React 19 build from before mid-2025 (check npm ls react) and the error appears when a dynamic(() => import(...), { ssr: false }) component mounts — no notFound() or redirect() involved.

Fix: upgrade Next.js, which pins a patched React. If you are on Next.js 15.3+ or any 16.x release, this variant is already fixed and your error is Cause 1 or 2.

Cause 4: Firefox timer precision makes it worse

A July 2026 comment on the issue added a browser dimension: Firefox ships privacy.reduceTimerPrecision enabled by default, which rounds performance.now() values. That rounding makes tiny negative deltas between two nearly simultaneous timestamps far more likely, so Firefox users hit the error more often than Chrome users on identical code — one Next.js maintainer could not even reproduce the original report in Chrome on macOS.

Confirm it: the error fires in Firefox but not Chrome on the same route, with Firefox's own wording (Given attribute end cannot be negative).

Fix: none needed beyond the workarounds below — but if your team is split on "works on my machine", the browser difference is why. This is also worth knowing before you burn an afternoon profiling: the measurement that crashes is React's internal component track, not anything from your own code, so tools from our Next.js performance optimisation guide will show nothing wrong.

Where the fix stands upstream

As of August 2026:

Issue #86060 is open and triaged by the Next.js team (labelled for their internal tracker).
PR #88688, which added the missing 0 <= childrenEndTime guard to the error and abort paths in Next.js's vendored React files, was closed unmerged in January 2026. Maintainer @eps1lon's reasoning: patching the compiled output masks the symptom, and the real fix belongs in facebook/react.
The ssr: false variant was fixed in react#32823 (April 2025) and has long since shipped inside Next.js.
No stable Next.js release fixes the notFound()/redirect() variant yet. Upgrading to the latest canary is worth a try after each React sync, but as of 16.1.6 the reports keep coming.

So unlike a stuck Turbopack compile, you cannot currently upgrade your way out of this one.

Workarounds while you wait

Three options, all confirmed by commenters on the issue, all dev-only:

1. Run the dev server on webpack. Several people independently confirmed this eliminates the error, because the unguarded measure call lives in the Turbopack-specific bundle:

next dev --webpack

The trade-off is real — you give up Turbopack's faster HMR — so treat it as the fallback, not the default. (Note the flag is --webpack; there is no environment variable that disables Turbopack.)

2. Relocate not-found.tsx. If your trigger is Cause 1, moving the file from inside the dynamic segment (app/[slug]/not-found.tsx) up to its parent (app/not-found.tsx) resolved it for at least one reporter, with 404 behaviour unchanged.

3. Patch performance.measure in development. The first comment on the issue shares this approach: wrap the native method and swallow only the negative-timestamp failure. Load it from your root layout, guarded so it can never reach production:

// instrumentation-client.ts (or imported in app/layout.tsx)
if (process.env.NODE_ENV === 'development') {
  const original = performance.measure.bind(performance)
  performance.measure = ((...args: Parameters<typeof original>) => {
    try {
      return original(...args)
    } catch (e) {
      if (e instanceof Error && e.message.includes('negative time stamp')) {
        return undefined as unknown as PerformanceMeasure
      }
      throw e
    }
  }) as typeof performance.measure
}

This is the bluntest option — it also hides any legitimate negative-timestamp bug in your own instrumentation — so delete it once the upstream fix lands.

Whichever you choose, remember the scope: this error never reaches your users. The throwing code is in a *.development.js bundle that production builds exclude, which is why nobody has ever reported it from a deployed site. If you are seeing runtime errors in production, you are looking at a different failure — start with our breakdown of ChunkLoadError: Loading chunk failed, and for other dev-mode-only surprises that look scarier than they are, see why useEffect runs twice in dev.

Originally published at https://www.iloveblogs.blog

DEV Community: Mahdi BEN RHOUMA

Test Supabase RLS Policies Before You Ship

Why Postgres skips your policy

The procedure

Run it as more than one person

Doing all four at once

What the measurements look like

Studio impersonation is closer, but it is still not production

Put it in CI

The short version

Supabase 42501: permission denied for schema auth

This is a boundary, not an oversight

Where each failure actually comes from

A client query against auth.users

A view over auth.users

A policy that joins auth.users

The fix: a security definer function

The better fix: stop needing the auth schema

Checklist

Supabase Hangs After onAuthStateChange: The Deadlock

The mechanism

Why it looks intermittent

The fix

What still counts as "a Supabase call"

Confirming it is this and not something else

Related failures that look identical from the outside

Fix AuthSessionMissingError: Auth session missing!

First: which call produced it?

Cause 1: a server client built without cookies

Cause 2: no middleware refreshing the session

Cause 3: reading the session too early on the client

Cause 4: nobody is signed in

A quick way to tell the causes apart

Related failures with different messages

Better Auth vs Supabase Auth 2026: Honest Verdict

The mechanism you are actually choosing between

Supabase Auth: the database knows who you are

Better Auth: your application knows who you are

The mistake to avoid: assuming they compose

Where each one is clearly right

The parts that do not decide it

A note for EU teams

The verdict

Switch Databases in psql: The \connect Command (2026)

The muscle-memory trap

The command

Switch user, host, or port at the same time

The transaction gotcha

Connect at launch instead

Exit psql

Supabase: connect to a specific project

Common mistakes

Related Articles

How to Drop All Tables in PostgreSQL Safely (2026)

Why you are here

The one-command reset

The PostgreSQL 15 gotcha that breaks this

The variant that keeps extensions

Drop only tables, keep everything else

The Supabase path: do not run DROP SCHEMA on production

The transaction wrapper for dev

Production safety checklist

Common mistakes

When you should not do this at all

TL;DR

Related Articles

Next.js useSearchParams Suspense: Static Rendering Fix 2026

The exact error and when it fires

Why Next.js refuses to statically render useSearchParams

The fix: split the page and wrap the reads in a Suspense boundary

Step-by-step: ship it without losing the static shell

Verify the route stayed static

Two patterns that still trip you up

Why this happens and how to keep it from coming back

FAQ

Related

Sign In to Supabase Without Email Verification (2026)

The friction

Option 1 — Turn it off in the dashboard (hosted dev)

Option 2 — Turn it off in config (self-hosted / local)