Two Supabase sessions, one browser: cookie partitioning for admin and customer auth

Art Levitt — Wed, 29 Apr 2026 20:01:21 +0000

A small Next.js + Supabase pattern that lets the same admin be logged in to both portals at once, without weird middleware hacks.

Most apps that have an admin area and a customer portal hit the same problem eventually: the admin who's debugging an issue wants to log in to a customer account without logging out of admin. With one shared Supabase session cookie, they can't. They sign into the customer portal, the admin session dies, and now they have to re-sign-in to admin afterwards.

Annoying for daily-driver admins. Disastrous when the admin is mid-debug at 2am and loses their place.

The fix is small and clean: give each "area" of the app its own Supabase cookie name. Two cookies, two parallel sessions, same browser.

The setup
In Next.js (with @supabase/ssr), the Supabase server client takes a cookieOptions.name option. By default it's a single global cookie name. Override it per area.

export type AuthArea = "admin" | "portal";
export const AREA_COOKIE_NAME: Record<AuthArea, string> = {
  admin: "sb-admin-auth-token",
  portal: "sb-portal-auth-token",
};
export const AREA_HEADER = "x-app-area";

In your middleware (Next 16: proxy.ts), resolve the area from the URL and write it to a request header so server code downstream knows which cookie to read:

export async function proxy(request: NextRequest) {
  const area = request.nextUrl.pathname.startsWith("/admin")
    ? "admin"
    : "portal";
  const requestHeaders = new Headers(request.headers);
  requestHeaders.set(AREA_HEADER, area);
  // ... refresh the right session, return response
}

And the Supabase server client reads the area from headers and picks the right cookie:

export async function getSupabaseServerClient(area?: AuthArea) {
  const cookieStore = await cookies();
  const hdrs = await headers();
  const resolvedArea: AuthArea =
    area ?? (hdrs.get(AREA_HEADER) === "admin" ? "admin" : "portal");
  return createServerClient(SUPABASE_URL, SUPABASE_ANON_KEY, {
    cookies: { /* getAll / setAll */ },
    cookieOptions: {
      name: AREA_COOKIE_NAME[resolvedArea],
    },
  });
}

That's the whole pattern. Two cookies, two sessions, one browser. The admin can be logged in as themselves on /admin/* and as a test customer on /portal/* simultaneously.

Why pass area as a parameter, not just rely on the header
The auth callback is the one place this matters. When a user signs in to the customer portal but the magic link is being processed in a route handler that runs outside the /portal/* URL prefix, the header-based detection picks the wrong area. Passing an explicit area argument lets the auth callback say "I know I'm finishing an admin sign-in - set the admin cookie".

const supabase = await getSupabaseServerClient("admin");
await supabase.auth.exchangeCodeForSession(code);

This is the kind of edge case that bites you on day 3 of the migration if you don't plan for it.

Caveats

RLS policies don't change. Both cookies authenticate the same auth.users row. If your admin happens to also have a customer record, RLS sees them as that customer in the portal area. That's almost always what you want.
Cookie size. You now ship two auth cookies on every request. They're small (~few hundred bytes each) but if you have other large cookies, watch your headers.
Sign-out has to be area-scoped too. Don't write a global "sign out" that nukes both cookies — let each area sign itself out independently.

When you don't need this
If your admin and customer flows don't overlap - same person never plays both roles — a single session is simpler. Don't add this complexity speculatively. Add it the first time an admin asks you "can I be logged in as both?".

Inngest's instanceof lies: why custom error classes vanish across step.run

Art Levitt — Wed, 29 Apr 2026 19:09:12 +0000

A small bug that will silently break your retry logic, your error reporting, and your dashboards.

We run a long pipeline through Inngest - voice generation that calls OpenAI, then ElevenLabs, then writes to storage, with a consent gate at the top. Each vendor call lives in its own step.run so a transient failure on one vendor doesn't replay the rest of the pipeline.

We classify failures with custom error classes:

export class TTSUpstreamError extends Error {
  constructor(public status: number, message: string) {
    super(message);
    this.name = "TTSUpstreamError";
  }
}
And the failure handler did the obvious thing:

function ttsReasonFor(err: unknown): string {
  if (err instanceof TTSUpstreamError) return `elevenlabs_upstream:${err.status}`;
  if (err instanceof TTSNotConfiguredError) return "elevenlabs_not_configured";
  return "elevenlabs_unknown";
}

Worked in dev. Worked in tests. In production, every failed run was logged as elevenlabs_unknown - including a real 402 from levenLabs that should have been classified as elevenlabs_upstream:402. We were debugging blind.

What's actually happening
Inngest's step.run wraps your function so the step result (success or failure) can be memoized. On a retry, instead of re-running the step, Inngest replays the memoized outcome. That requires serializing everything across the step boundary - including thrown errors.

When an error crosses that boundary, Inngest preserves error.name and error.message (and error.stack if you're lucky). What it does not preserve is class identity. By the time your catch block sees the error, it's a plain Error object with the right shape but a different prototype.

So err instanceof TTSUpstreamError returns false. Always.

The fix
Match on err.name, not on class identity. name survives serialization. Keep the instanceof check too, for the case where the throw happens outside a step.run - there, the original class identity is intact.

function ttsReasonFor(err: unknown): string {
  if (!(err instanceof Error)) return "elevenlabs_unknown";
  const name = err.name;
  const msg = err.message ?? "";
  if (name === "TTSNotConfiguredError") return "elevenlabs_not_configured";
  if (name === "TTSUpstreamError") {
    const status = msg.match(/status=(\d{3})/)?.[1] ?? "0";
    return `elevenlabs_upstream:${status}`;
  }
  // Direct throws (outside step.run) keep class identity intact.
  if (err instanceof TTSUpstreamError) return `elevenlabs_upstream:${err.status}`;
  if (err instanceof TTSNotConfiguredError) return "elevenlabs_not_configured";
  return "elevenlabs_unknown";
}

Two things to notice:
We pull the status code back out of the message string. That's only possible because we put it there in the first place when constructing the error: new TTSUpstreamError(402, "ElevenLabs failed (status=402)"). If your error messages don't include structured data, add it now - your future self inside an Inngest step will thank you.
We keep the instanceof checks as a fallback. Because the rule is "class identity dies when crossing a step boundary" - but if the throw originates outside step.run, identity is intact and instanceof is the cleaner check.
Why this matters beyond Inngest
Any serialization boundary does this. Same problem appears in:

Web Workers (postMessage strips prototypes)
Any RPC framework
Anything that JSON-serializes errors for logging
If you're going to depend on error type in a system that crosses any of these boundaries, encode the type in name and structured data in message (or in a custom code / data field). Treat instanceof as a happy-path optimization, not a guarantee.

The rule of thumb: if your error has to leave the process - or even just leave the Promise it was thrown in - assume the prototype chain is gone when you catch it.

DEV Community: Art Levitt

Two Supabase sessions, one browser: cookie partitioning for admin and customer auth

Inngest's instanceof lies: why custom error classes vanish across step.run