[pull] master from supabase:master#708
Merged
pull[bot] merged 13 commits intocode:masterfrom Feb 26, 2026
Merged
Conversation
The SDK now handles orphaned lock recovery via steal internally (supabase-js#2106). Keep the BroadcastChannel observability wrapper for Sentry signals. The steal-based orphaned lock recovery in `debuggableNavigatorLock` (packages/common/gotrue.ts) (introduced in #39868) is now redundant, supabase-js#2106 handles this natively in the SDK. Removes the `navigator.locks.request({ steal: true })` block while keeping the BroadcastChannel wrapper that sends lock-holder stack traces to Sentry. Related: supabase/supabase-js#2106, supabase/supabase-js#2125
## 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? A new feature page ## What is the current behavior? N/A ## What is the new behavior? N/A ## Additional context Add any other context or screenshots. Co-authored-by: Ana Mogul <ana1337x@users.noreply.github.com>
Feature enhancement — smarter incident banner targeting logic ## What is the current behavior? Displaying the incident banner requires toggling a flag or environment variable. Banners are shown to all users regardless of whether their projects are in affected regions or whether the incident affects project creation. ## What is the new behavior? Banner visibility is now driven by `show_banner` metadata from the StatusPage API — no manual flag or env var toggle needed. Per-user targeting is then applied: - Users with projects only see the banner when they have a database in an affected region - Users without projects only see the banner when the incident affects project creation Incident responses are enriched with cache data (`affected_regions`, `affects_project_creation`) fetched from a Supabase table. Visibility logic is extracted into a dedicated hook and pure utility function, backed by unit tests. ## Additional context Resolves FE-2562
…ddleware matchers (#43153) ## 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)
In the db charts, numbers in the Y axis are not formatted, sometimes these get too big and get cut-off. ## before (in this example it is not cutoff because the number is not big enough) <img width="1020" height="634" alt="CleanShot 2026-02-25 at 11 20 35@2x" src="https://github.com/user-attachments/assets/bc29edcc-331f-44d1-934f-1553b895c338" /> ## after <img width="936" height="676" alt="CleanShot 2026-02-25 at 11 21 07@2x" src="https://github.com/user-attachments/assets/eae4ea4c-b8cd-4fe4-a361-9b029955217b" />
The Y axis domain/range was being calculated incorrectly. Testing this is a bit painful. You need to: - using tweak-extension or similar overwrite the API response for the IOPS chart and add a really big value - reload the page - the Y axis should adapt to that really big value even if it goes over the disk max iops See screenshots below ## before - big data point wouldn't change the chart range - Y Axis max is 6k even tho we have a data point over 20k <img width="1204" height="714" alt="CleanShot 2026-02-25 at 18 47 14@2x" src="https://github.com/user-attachments/assets/881aff6e-22a2-408d-b2c4-5a27f3fda386" /> ## after - the Y axis shows the correct range <img width="932" height="786" alt="CleanShot 2026-02-25 at 18 47 57@2x" src="https://github.com/user-attachments/assets/6247c66e-4b3e-49e9-9f6b-086086913fab" />
…are (#43189) 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
…3183) ## What kind of change does this PR introduce? Changes the base font weight for strong tags within the tailwind/typography configuration. ## What is the current behavior? I noticed that texts within our strong tags had an irregular stroke, and problems on rendering. The main problem is we are using the default 600 weight value coming from the config of tailwind, while our Circular custom font supports 400 and 600. _See the first text in the list from the screen just, like "Multi Protocol"._ <img width="717" height="555" alt="Screenshot 2026-02-25 at 16 10 29" src="https://github.com/user-attachments/assets/1063f049-ba9d-45a4-9946-ec4a0e380c48" /> ## What is the new behavior? Strong tags now render with 500 font weight to prevent bad text rendering. <img width="674" height="505" alt="Screenshot 2026-02-25 at 16 12 56" src="https://github.com/user-attachments/assets/383e895d-e2b7-4d92-9357-403396ca2722" />
…s middleware (#43190) 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
…3191) ## 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? I modified previous webinars to include the following: - A YouTube embed of the recording - New "Watch the Recording" CTA buttons - New slug for the go page `/vibe-coding-done-right-webinar` --------- Co-authored-by: Alan Daniel <stylesshjs@gmail.com> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
github-actions
bot
added
the
documentation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )