When a user renames their tunnel subdomain, the upsert (onConflict=user_id)
overwrote the tunnels row in place, but the old subdomain's Redis
tunnel:active:<sub> flag was never cleared. The edge tunnel-active gate kept
serving the stale flag for up to its ~30s TTL, after which it fell back to a
Postgres miss and (currently) returned a misleading suspended response.
Capture the user's previous subdomain before the upsert and, when it changes,
DEL the old kill-switch key (new clearTunnelActive helper) so the edge gate
immediately stops treating the old subdomain as a live tunnel.
@supabase/ssr derives the auth cookie storage key from the hostname of the URL
it is given (sb-<sub>-auth-token). After routing server-side clients at the
internal host (kong-prod), the server looked for sb-kong-prod-auth-token while
the browser had set sb-api-auth-token, so server-side getUser() never found the
just-established session and bounced the user off the MFA challenge back to
/login. Pin every client (browser, server, middleware) to the name derived from
NEXT_PUBLIC_SUPABASE_URL via a shared helper so the namespace stays consistent
regardless of which API endpoint the client talks to.
Server-side Supabase calls (middleware getUser/refresh, server components,
admin client) all egress through the Docker gateway as a single NATed IP and
traverse Caddy's per-IP /auth/* rate limiter (8 events/s). A handful of active
users saturate that shared bucket, 429ing getUser()/token refresh; the
middleware then treats the session as invalid and bounces to /login, while a
manual refresh lands under budget and works again.
Add SUPABASE_INTERNAL_URL (e.g. http://kong-prod:8000) used only by the
server-side clients (middleware, lib/supabase/server.ts, admin getSupabaseAdmin
/getSupabaseAnon), falling back to the public URL when unset. Browser clients
keep the public URL so real per-user-IP edge rate limiting still applies.
Also bake the arg in the Dockerfile/build and make the web-prod network alias
durable via WEB_ALIAS (dev sets web-dev) so the dev container can't reclaim the
web-prod alias on redeploy.
The upstream admin gateway deterministically truncates the first per-row
getUserById that immediately follows a request's auth check, yielding an
empty body the per-call retry cannot clear — so a couple of tunnel rows
showed owner_email '—' on every load regardless of retry or concurrency.
Replace the per-row getUserById fan-out with a single bounded listUsers
scan (same transient retry) that builds an id->email map and stops early
once every owner on the page is resolved. A single listUsers read does not
hit the truncation pattern, eliminating the dashes. Remove the now-unused
mapWithConcurrency helper and OWNER_EMAIL_CONCURRENCY constant.
The upstream admin gateway tolerates only a small concurrent burst; at
concurrency 4 the tail of the per-row getUserById fan-out was truncated
into empty bodies on every list load (deterministic '—'), and the retries
piled into the same throttle window. Measured 0 failures at concurrency 2
(and 1) versus consistent truncations at 4, so pin enrichment to 2.
A large concurrent burst of getUserById calls during the tunnels-list
email enrichment self-inflicts an upstream throttle (truncated/empty
bodies) that even the per-call retry can't fully escape, intermittently
rendering owner_email as '—'. Add mapWithConcurrency and resolve owner
emails at most a few at a time so each lookup stays inside the throttle
allowance; retry + null fallback preserved.
Gerhard Scheikl