## Context
Resolves FE-3077
Related discussion: https://github.com/orgs/supabase/discussions/45233
Verifying the correctness of your RLS policies set up has always been a
gap, as highlighted by a number of GitHub discussions like
[here](https://github.com/orgs/supabase/discussions/12269) and
[here](https://github.com/orgs/supabase/discussions/14401). As such,
we're piloting a dedicated UI for RLS testing (using role impersonation
as the base), in which you'll be able to
- Run a SQL query as a user (not logged in / logged in - this is the
role impersonation part)
- See which RLS policies are being evaluated as part of the query
- And hopefully be able to debug which policies are not set up correctly
Changes are currently set as a feature preview - and we'll iterate as we
get feedback from everyone 🙂🙏
<img width="613" height="957" alt="image"
src="https://github.com/user-attachments/assets/83c37f8a-28fc-43b3-b0ff-e28571d8710c"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* RLS Tester: run queries as anon or authenticated users, view inferred
SQL, per-table policy summaries, and data previews of accessible rows.
* UI preview: new RLS Tester preview card and modal with opt-in toggle;
RLS Tester sheet with role/user selector and query editor.
* SQLEditor: “Explain” tab is always visible.
* **Chores**
* Added supporting API endpoints, background checks for table RLS
status, and a local-storage flag to persist the preview opt-in.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Feature
## What is the current behavior?
Incident banner logic depends on StatusPage and Supabase project for
metadata.
## What is the new behavior?
New incident banner logic that depends only on incident.io. Displays in
non-production environments for now because I haven't wired up the rest
of the workflow. This is just to allow a total end-to-end
testing/playground for test incidents <-> Slack <-> preview dashboard
for people to try out the UX.
## Additional context
You can test using my [test
incident](https://app.incident.io/supabase/incidents/405). This has
severity minor, so the preview site should have a banner. Toggle to
informative, hard refresh dashboard with cache off, and banner should
disappear. Toggle back to minor, hard refresh without cache again, and
banner should reappear. Same thing if you edit the "Banner shown" field
from 1 to -1 and back.
New feature — adds a platform-only API endpoint to Studio.
## What is the current behavior?
`NEXT_PUBLIC_ONGOING_INCIDENT` is not exposed outside of the dashboard.
## What is the new behavior?
`GET /api/status-override` returns `{ enabled: boolean }` indicating
whether `NEXT_PUBLIC_ONGOING_INCIDENT` is set to `"true"`. The endpoint
returns 404 on self-hosted and is added to the proxy allowlist for
hosted platform access.
This is so that the incident banner bot can detect whether an override
is in place.
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
This introduces a small snippet preview of the error code coming via our
content API for the docs. This appears in a couple of places right now.
- **Auth Overview** - This page isn't fully released yet, but it appears
on the error codes table (as depicted below).
- **Logs** - When you delve into the logs panel, if there's an error
code available, they're also wrapped in this popover.
We are also working on a shared-data package (#43458) to potentially
replace this endpoint internally. Also introduces a multifaceted button
to debug/fix with either Assistant or LLM of choice.
| Auth Overview | Logs Panel |
|--------|--------|
| <img width="407" height="287" alt="Screenshot 2026-03-09 at 14 14 09"
src="https://github.com/user-attachments/assets/7450dddb-6828-4cd3-802d-37d47ba1b440"
/> | <img width="394" height="216" alt="Screenshot 2026-03-09 at 14 13
56"
src="https://github.com/user-attachments/assets/80c2a46e-dbe4-4e88-a0a7-68b977a71d6b"
/> |
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Summary
- Reverts the middleware changes to `apps/studio` and `apps/docs` from
#43153 that caused full page reloads on every client-side navigation in
Studio
- Root cause: broadening the `middleware` matchers to match all routes
and returning `NextResponse.next()` unconditionally interferes with
client-side navigation in the multi-zone production setup (`www` proxies
`/dashboard/*` → Studio, `/docs/*` → Docs)
- Cookie stamping is unnecessary in Studio and Docs because `apps/www`
sits in front of both apps in production and already handles
first-referrer cookie attribution for all incoming traffic
- The `apps/www` middleware, packages/common cookie utilities, and
telemetry changes from #43153 are left intact
Test plan
- Verify client-side navigation works without full page reloads in
Studio (production or preview deploy)
- Verify first-referrer cookie is still stamped via `www` middleware on
initial visit
Summary
- Fixes full page reloads on every client-side navigation in Studio
caused by the first-referrer cookie middleware (#43153)
- In the multi-zone production setup (www proxies /dashboard/* →
Studio), returning `NextResponse.next()` unconditionally processes every
response through Next.js's middleware pipeline, interfering with
client-side navigation
- Now only returns NextResponse.next() when a cookie actually needs to
be stamped; returns undefined otherwise so Next.js handles the request
untouched
- Also fixes valid API routes (e.g. /api/ai/sql/generate-v4) falling
through to cookie-stamping code instead of passing through cleanly
## Summary
Re-lands the first-referrer cookie feature from #42768 (reverted in
#43129) with middleware matcher fixes that prevent Studio traffic
interference.
**Tracks:** [GROWTH-651](https://linear.app/supabase/issue/GROWTH-651)
## What changed
New shared module in `packages/common/first-referrer-cookie.ts` that
handles stamping and parsing a first-referrer cookie (referrer, UTMs,
click IDs, landing URL). Each app's middleware calls
`stampFirstReferrerCookie` on the edge response — www and docs are the
primary entry points, Studio is a fallback for direct visits with UTMs.
On the telemetry side, `handlePageTelemetry` now takes an options object
instead of positional args, reads the cookie on initial pageview, and
overrides the referrer if the cookie captured an external source but the
current referrer is internal (i.e., the user navigated cross-app). Also
sends `first_referrer_cookie_present`/`consumed` properties so we can
observe the handoff in PostHog.
The docs middleware matcher was broadened from `/reference/:path*` to
all docs pages so we stamp cookies site-wide, not just on reference
paths.
## Root cause of original revert
Two layers:
1. **Matcher gap**: www middleware ran on `/dashboard/*` traffic in prod
due to Vercel Multi-Zone architecture (www is the gateway for
`supabase.com`, proxying `/dashboard` → Studio, `/docs` → Docs).
Middleware runs *before* rewrites, so www middleware executed on all
proxied traffic.
2. **`_next/data` interception**: The matcher didn't exclude
`_next/data` paths. Client-side navigation in Next.js fetches JSON via
`/_next/data/...` — middleware intercepted these, returned
`NextResponse.next()` with cookie mutations (which processes through the
middleware response pipeline), and this interfered with the JSON
responses, causing full page reloads in the SQL editor.
## How this PR fixes it
| Fix | Detail |
|---|---|
| Exclude `_next/data` | All three matchers (`www`, `docs`, `studio`)
exclude `_next/data` via negative lookahead |
| Exclude `dashboard` + `docs` from www | www middleware no longer runs
on proxied app traffic |
| `/api/` path guard in Studio | Broadened matcher requires explicit
path check for API route filtering |
| `NextResponse.next()` semantics | Cookie stamping only happens on
matched paths; unmatched paths never enter middleware |
### `NextResponse.next()` vs `undefined` nuance
Returning an explicit `NextResponse.next()` with cookie mutations
processes through Next.js's middleware response pipeline (headers are
merged, cookies are set). Returning `undefined` (i.e. the request never
matches the matcher) lets Next.js handle the request completely
untouched. The matcher exclusions ensure `_next/data` and proxied app
paths never enter middleware at all.
## Testing
- ✅ 22 unit tests for shared cookie utilities (all pass)
- ✅ Studio prod build succeeds, middleware recognized as `ƒ Proxy
(Middleware)`
- ✅ Playwright validation: client-side navigation works across 3 page
transitions, `_next/data` requests return 200 OK without middleware
interception, no full-page reloads
- ❌ www/docs SSG builds require platform backend services (expected —
same as master)
## Summary
Fixes GROWTH-625.
Preserves first-touch attribution across app boundaries by persisting
external referrer context at the edge and consuming it on Studio's
initial pageview.
When users come from an external source to www/docs and then navigate to
Studio, Studio often only sees the internal `supabase.com` hop. This
change preserves the original external context so first-touch
attribution is retained.
## What changed
- **Shared first-referrer cookie utilities**
(`packages/common/first-referrer-cookie.ts`):
- `isExternalReferrer`, `buildFirstReferrerData`,
`serializeFirstReferrerCookie`, `parseFirstReferrerCookie`
- `hasPaidSignals` — detects click IDs (gclid, fbclid, etc.) and paid
utm_medium values
- `shouldRefreshCookie` — centralizes stamp-or-skip decision for all
apps
- `stampFirstReferrerCookie` — shared middleware helper used by all apps
(extracted from duplicated inline logic)
- **Edge middleware on all apps** — stamps cookie for external visitors,
refreshes on paid signals:
- `apps/www/middleware.ts` (simplified to use shared helper)
- `apps/docs/middleware.ts` (simplified to use shared helper)
- `apps/studio/proxy.ts` (integrated into existing proxy file)
- **Docs middleware matcher** — broadened from `/reference/:path*` to
all non-static paths so the first-referrer cookie is stamped on all docs
pages, not just reference paths
- **Telemetry** — Studio consumes cookie on initial pageview
(`packages/common/telemetry.tsx`). `handlePageTelemetry` refactored from
7 positional params to an options object for readability.
- **Tests** — 22 unit tests covering all utilities and edge cases
(including direct-navigation scenario)
## Behavior
- Writes `_sb_first_referrer` cookie when:
- cookie is not already set and request has an external referrer, OR
- cookie exists but incoming URL has paid traffic signals (click IDs or
paid utm_medium)
- Cookie: 365-day TTL, `domain=supabase.com`, `sameSite=lax`,
`secure=true` in production
- On first Studio pageview, if current referrer is internal and cookie
has external context:
- use persisted external referrer
- apply persisted UTM/click-id/landing-url attribution props
- Measurement properties: `first_referrer_cookie_present`,
`first_referrer_cookie_consumed`
## Manual testing
1. Visit `supabase.com/pricing?utm_source=google&utm_medium=cpc` from an
external referrer (or use DevTools to set a `Referer` header)
2. Check `_sb_first_referrer` cookie is set in Application > Cookies
3. Navigate to Studio (`supabase.com/dashboard`)
4. In PostHog (or browser network tab), verify the first `$pageview`
event has:
- `first_referrer_cookie_present: true`
- `first_referrer_cookie_consumed: true`
- `$utm_source: "google"`, `$utm_medium: "cpc"`
- `$referrer` points to the external source, not `supabase.com`
5. Verify subsequent route changes do NOT include
`first_referrer_cookie_*` properties
## Review feedback addressed
- Added `secure: true` flag on production cookies (Pam's first comment)
- Fixed inaccurate JSDoc on `utms` field — keys retain `utm_` prefix
(Pam's fourth comment)
- Added test coverage for edge cases: malformed URLs, multi-cookie
headers, http:// referrers (Pam's sixth comment)
- Docs matcher broadening: fast-path exit on cookie-exists check keeps
overhead minimal, exclusion list is correct
- Extracted shared middleware helper to eliminate duplication across 3
apps
- Refactored `handlePageTelemetry` from positional params to options
object
- Removed redundant null check in `hasPaidSignals`
- Added direct-navigation test case
- Deleted dead `apps/learn/middleware.ts`
- Fixed studio build: integrated cookie stamping into existing
`proxy.ts` (Next.js 16 rejects both middleware.ts and proxy.ts)
---------
Co-authored-by: pamelachia <26612111+pamelachia@users.noreply.github.com>
Co-authored-by: Pamela Chia <pamelachiamayyee@gmail.com>
## Summary
Removes two concluded A/B experiments that didn't produce positive
results:
- **tableQuickstart**: Tested AI-powered table generation, template
selection, and assistant integration for new table creation
- **realtimeButtonVariant**: Tested hiding the realtime button or
replacing it with a triggers button
## Changes
- Delete `TableQuickstart/` folder with AI widget, templates widget, and
generation hooks
- Delete `useRealtimeExperiment` hook and remove variant-conditional
logic
- Delete `/api/ai/table-quickstart/generate-schemas` endpoint
- Remove telemetry event definitions for both experiments
- Remove local storage exposure tracking key
- Remove API endpoint from proxy whitelist
- Clean up eslint baseline references
## Testing
- [x] Tested locally - Table Editor renders correctly without experiment
widgets
- [x] TypeScript compiles without errors
- [x] No remaining references to removed experiment code
**Quick test:**
1. Navigate to Table Editor → New Tab shows only "Create a table" card
(no AI/Templates/Assistant variants)
2. Open table create panel → Realtime checkbox shows unconditionally
when realtime is enabled
## Linear
fixes GROWTH-609
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Removed Features**
* AI-powered table generation and quickstart assistance (templates, AI
widget, generation hook, templates data, and related utilities)
* Quickstart templates widget and predefined table templates
* Database triggers management interface
* Realtime experiment gating and related experiment variants
* **API & Storage**
* Hosted AI quickstart API endpoint removed
* Local storage key for quickstart exposure tracking removed
* **Telemetry**
* Quickstart- and realtime-experiment telemetry events removed
* **UI Changes**
* Simplified realtime toggle control in the table editor
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
* add initial installation flow of stripe sync engine
* update docs link
* Add supabase_vault extension dep
* Add stripe logo to sync engine integration
* Move overview content to bottom of integration pages
* Add sync state to stripe sync page
* only check sync state if stripe integration is installed
* Use proper stripe-sync package and setup flows
* Improve sync engine installation ux
* Remove unused hardcoded dep
* Add alpha status to stripe sync engine integration
* fix typo
* run format
* fix types
* Rename the stripe-sync path to remove the 'integration". The path needs to have BASE_PATH to work on prod.
* Design tidy up (#41337)
UI tidy up
* update to latest sync engine package
* Add stripe key verification
* Remove noop try/catch
* Add integration isntallation telelemtry
* Add basic settings page
* Address coderabbit comments
* remove unused dep
* Remove state setting on render
* s/description/comment
* Cleanup settings screen UI
* Improve settings screen design
* update schema test snapshot
* Use latest stripe-sync-engine package
* Update repo url to new official location
* revert marketing change
* Update stripe sync engine package
* Add link to table from overview page
* Add feature flag and improve telemetry
* Fix missing useMemo dep
* add uninstall telemetry note
---------
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
Co-authored-by: Saxon Fletcher <saxonafletcher@gmail.com>
Incident status banners/alerts should be automatically determined from
the status page, rather than being manually configured.
Adds a new endpoint, /api/incident-status, to return information about
active incidents. This information is fetched from the StatusPage API.
The endpoint is cached to reduce number of third-party API requests.
Co-authored-by: Ali Waseem <waseema393@gmail.com>
* Bump Nextjs to v16.
* Fix studio issues.
* move docs graphiql css import to layout
* update sentry
* add missing docs package and fix imports
* only update studio
* ignore next-env.d.ts
* update bundle analyzer
* middleware to proxy
* update lockfile
* remove --turbopack dev flag as it's the default
* Import only types from the monaco editor.
---------
Co-authored-by: Alaister Young <a@alaisteryoung.com>
Joshen Lim