## 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?
Feature / refactor.
## What is the current behavior?
The dashboard assistant runs `@supabase/mcp-server-supabase` in-process
over an in-memory transport (`lib/ai/supabase-mcp.ts`).
## What is the new behavior?
The assistant connects to the **remote MCP server** over HTTP
(`@ai-sdk/mcp`), forwarding the dashboard session token as a bearer. URL
comes from `NEXT_PUBLIC_MCP_URL` with a local-dev fallback;
platform-only, and Nimbus works via the same env var.
* **Tool model unchanged:** UI-controlled `execute_sql` (with
`needsApproval`) and `deploy_edge_function` still come from Studio; the
allowlist (`TOOL_CATEGORY_MAP`) remains the gate keeping the remote's
write tools away from the assistant (`read_only` is defense-in-depth).
* **Attribution:** sends `x-source-name: supabase-studio` (+
`x-source-version`) → logged as `source_name`/`client_name`.
* **Connection lifecycle:** the HTTP client is closed via the request's
`AbortSignal` (tools execute later during streaming); `signal` is
required on `getTools`/`getMcpTools`.
* **Resilience:** a remote-MCP failure degrades to the remaining tools
instead of failing the assistant.
* **Drift protection:** relied-upon tools are typed against `keyof
typeof supabaseMcpToolSchemas`, so a package bump that renames/removes
one fails `pnpm typecheck`; a runtime check also warns if the deployed
server returns fewer tools.
* Adds unit tests for the above.
## Additional context
* Verified end-to-end against a local remote MCP server with a dashboard
token: `initialize` 200, tools listed, a tool executed, client closed
cleanly.
* The remote MCP (mgmt-api) already accepts dashboard session tokens
(GoTrue-JWT auth path) — no backend change needed. `NEXT_PUBLIC_MCP_URL`
must point at each env's `/mcp`.
* `@supabase/mcp-server-supabase` is kept — still used by the
self-hosted `/api/mcp` routes.
Closes
[AI-137](https://linear.app/supabase/issue/AI-137/switch-dashboard-assistant-to-remote-mcp)
## Rollout
* **Rollout:** merges with `USE_REMOTE_MCP` off (in-process); flip it to
`true` per environment (staging → prod → Nimbus) once each one's
prerequisites land.
* **Rollback:** unset `USE_REMOTE_MCP` and redeploy to fall back to the
in-process client — no revert needed.
## Summary by CodeRabbit
* **Bug Fixes**
* Improved AI request handling so tool loading and generation clean up
properly when a request is cancelled or the browser connection closes.
* Added safer fallback behavior when remote tool loading fails, so AI
features can continue with available tools instead of stopping entirely.
* Updated remote tool access to use the current project reference and
preserve the correct access headers.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* AI tools now connect more reliably to remote services and stop cleanly
when requests end or are canceled.
* Tool loading is more resilient, continuing with available tools if
remote access is unavailable.
* **Bug Fixes**
* Improved cleanup to prevent lingering connections during SQL
generation and policy workflows.
* Added safer handling for remote tool changes and invalid responses.
* **Tests**
* Expanded automated coverage for remote tool setup, cancellation, and
fallback behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Problem
Because some tests were taking too much time before with the studio
supabase default instance, we used to do a reset of its config on CI.
This makes local testing more cumbersome as you have to manually reset
it without forgetting to create a `functions` directory.
## Solution
- prepare the existing e2e supabase config in `e2e/studio` to ensure
functions work (create the directory)
- use the `workdir` option of the supabase CLI so that it uses the
`e2e/studio` specific config
- remove the now unnecessary reset done on CI
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved the reliability of the end-to-end setup flow by simplifying
cleanup steps and avoiding an extra reset during shutdown.
* **Chores**
* Updated workflow and script behavior to better support automated test
runs without changing the user experience.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What
Routes the **Dart/Flutter v2** reference through the new
reference-content pipeline (`scripts/build-reference-content.ts` +
`spec/reference/dart/v2/`), the same one JavaScript v2 already uses.
Dart v1 stays on the legacy YAML pipeline.
## How
Dart has no upstream TypeDoc dump, so this follows the reference
README's "adapt other formats as a pre-step" approach:
- **`scripts/generate-dart-reference.ts`** converts the committed legacy
spec (`spec/supabase_dart_v2.yml`) plus the shared section tree into a
TypeDoc-shaped dump at `spec/reference/dart/v2/supabase_flutter.json`
(gitignored, like every other dump). Each Dart method becomes a
`variant: 'declaration'` node tagged with `@category`/`@subcategory` and
carries the legacy function shape (description, notes, params, examples)
on a non-TypeDoc `content` field.
- **`build-reference-content.ts`** gains a small, backward-compatible
addition: it spreads a declaration's `content` straight onto the
`functions.json` entry. The renderer then shows params/examples/notes
exactly as the legacy YAML did, with no typeSpec round-trip. The field
is absent for real TypeDoc dumps, so **JavaScript output is unchanged**
(existing JS snapshot still passes).
- `dart-v2` added to `SUPPORTS_NEW_REFERENCE_PROCESS`; the v2 `specFile`
is dropped from the nav entry so the legacy generator skips it.
- Dart search ingest switched to the new-pipeline loader.
- `config.json` + hand-authored partials (intro markdown,
`initializing`, and subcategory overviews like `using-filters`,
`auth-mfa`) added under `spec/reference/dart/v2/partials/`, mirroring
the JS lib.
- The dart dump is regenerated in `codegen:references:new` and in CI; a
self-contained `dart/v2` snapshot test covers the full YAML → dump →
content path.
## Verification
- `vitest run scripts/build-reference-content.test.ts` — both JS and
Dart snapshots pass.
- 112 function sections all resolve to renderable `functions.json`
entries (104 methods + 7 subcategory overviews + `initializing`).
- `tsc --noEmit` clean for all changed files.
- Legacy generator confirmed to skip dart v2 (only `dart.v1.*`
regenerated).
> Note: the live dev server (which needs the Supabase backend) was not
run; verification was done at the data-pipeline level plus parity with
the production JS pipeline behavior.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added Dart v2 reference documentation sections, including Installing,
Initializing, Filters, Modifiers, Auth Admin, MFA, Passkeys, File
Buckets, Introduction, and Upgrade guidance.
* Expanded the Dart v2 reference pipeline so Dart API pages are
generated from the newer reference content flow.
* **Bug Fixes**
* Improved Dart reference rendering by preserving legacy descriptions,
notes, params, and examples in generated function entries.
* Updated Dart v2 reference search to use the new pipeline’s generated
content so results and navigation stay in sync.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Jeremias Menichelli <jmenichelli@gmail.com>
## Problem
- We still use/maintain the legacy theming even though we moved to
Shadcn
- We have two themes list with similar code
## Solution
- Migrate some components to `cva` and `cn` instead of `styleHandler`
- Remove redundant `themes` in favor of `singleThemes`
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Standardized theme selection across the app so theme menus
consistently offer the same light/dark/system options, including
dropdowns, navigation menus, and command menus.
* **Refactor**
* Refreshed styling for multiple shared UI components (menus, tabs, side
panels, loading indicators, icons, and modal dialogs) to improve
consistency while preserving visual behavior.
* **Chores**
* Improved the UI patterns CI “validate exports” check for clearer
failure output when exports change unexpectedly.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
`ui-patterns` exports its components under a subpath (see its
`package.json`). This is easy to forget when adding a new component.
## Solution
Add a CI job that validate the exports are corrects
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Tests**
* Added a new “Validate exports” step to the UI patterns pipeline to
ensure generated exports remain in sync.
* When discrepancies are detected, the workflow outputs the diff and
fails immediately to prevent stale artifacts.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
## Summary
Since the guides UA-redirect shipped (GROWTH-811), named LLM bots
requesting `/docs/guides/*` get rewritten to the markdown handler, which
returns a 404 when no `.md` file exists. About 90K of those 404s per day
land on real pages that serve HTML 200 fine: the bot gets nothing on a
page that works.
The root cause is that the docs middleware hardcoded
`hasMarkdownVariant: true` for every guide path, so it never checked
whether a `.md` actually existed. I fixed it in two layers:
1. A build-time slug manifest makes `hasMarkdownVariant` truthful. Guide
pages with no `.md` now fall through to HTML 200 instead of a 404. This
is content-source-agnostic and future-proof: a new content source can
never silently regress to a 404.
2. A second generator pass emits real markdown for the troubleshooting
collection (the largest source, ~70% of the 404 volume), so those bots
get clean markdown rather than just HTML.
## Changes
- Add a shared `markdown-sources` module: a single source of truth for
which slugs get a `.md` (guides + troubleshooting), so the generator
output and the manifest cannot drift.
- Generate markdown for the troubleshooting collection (196 pages, TOML
frontmatter parsed via `smol-toml`), written under
`public/markdown/guides/troubleshooting/`.
- Emit a build-time slug manifest (a gitignored generated `.ts` module,
regenerated in `prebuild`, `predev`, and `pretypecheck`, mirroring the
existing `__generated__/graphql.ts` lifecycle).
- Gate the middleware's `hasMarkdownVariant` on the manifest: serve HTML
200 instead of a 404 for guide paths with no markdown variant.
This PR intentionally does not generate markdown for the ai-prompts,
YAML config, and externally-fetched (splinter) sources. The HTML
fallback covers them now; generating their markdown is follow-up work.
## Testing
Local verification (deterministic, against the real manifest and the
real negotiation function):
- Manifest invariant holds: 744 manifest slugs equal 744 generated `.md`
files.
- Generator emits 196 troubleshooting files with zero warnings,
frontmatter stripped, no leaked delimiters.
- Negotiation decision matrix, 6/6: covered slug + bot UA to markdown;
uncovered real page + bot UA to pass (HTML 200); nonexistent + bot UA to
pass; browser to HTML; covered + `.md` suffix to markdown; uncovered +
`.md` suffix to pass.
Verified on the Vercel preview deploy:
- [x] `User-Agent: ChatGPT-User` on a troubleshooting page returns `200
text/markdown` (real markdown body, frontmatter stripped).
- [x] `User-Agent: ChatGPT-User` on an uncovered real page
(`ai-tools/ai-prompts/code-format-sql`) returns `200 text/html` (was
404).
- [x] Browser request to the same uncovered page returns `200 text/html`
(unchanged for humans).
- [x] `User-Agent: ChatGPT-User` on a covered standard guide returns
`200 text/markdown` (no regression).
- [x] `User-Agent: ChatGPT-User` on a nonexistent guide URL returns
`404` (correct).
Known limitation: an explicit `.md`-suffix request on an uncovered page
still 404s by design (an explicit markdown request for a page that has
no markdown). The ~90K/day volume is plain-URL UA-based, so it is
unaffected.
Post-deploy, I will re-run the request-grain 404 reclassification in the
GROWTH-915 BQ workspace to confirm fixable guide markdown 404s drop to
near zero.
## Linear
- fixes GROWTH-946
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added generated markdown slug tracking for docs guides, improving
markdown availability detection.
* Added automated manifest generation and validation during docs build
and CI workflows.
* **Bug Fixes**
* Improved guide markdown negotiation so only supported guide slugs are
treated as having a markdown variant.
* Standardized markdown source handling for guides and troubleshooting
pages.
* **Tests**
* Added coverage for guide and troubleshooting slug generation.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
## Problem
The Selfhosted Studio E2E Tests workflow fails on community (fork) PRs
at the **configure aws credentials** step with:
> Credentials could not be loaded, please check your action inputs:
Could not load credentials from any providers
GitHub does not pass repository secrets to workflows triggered by
`pull_request` from a fork (a deliberate security measure). So on fork
PRs:
- `${{ secrets.PROD_AWS_ROLE }}` evaluates to an empty string, and
- the OIDC `id-token` token isn't available either,
so `aws-actions/configure-aws-credentials` falls through its entire
provider chain and errors out, failing the job.
## Fix
Guard the AWS credential + ECR login steps with
`!github.event.pull_request.head.repo.fork`, the same pattern already
used by the Playwright comment step in this workflow. These steps only
exist to authenticate with AWS ECR to avoid Docker pull rate limiting,
so on fork PRs we simply skip them and pull from `public.ecr.aws`
anonymously, letting the e2e tests run instead of erroring out.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Improved CI/CD pipeline security configuration to better safeguard
authentication credentials during external contributions.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
As the e2e workflow starts the Supabase CLI, it downloads all our images
from the AWS ECR for every run. This makes many anonymous pulls that are
rate limited.
## Solution
Authenticate on AWS ECR
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Chores
* Updated the Studio E2E test workflow to include AWS ECR
authentication. The workflow now uses tightened job permissions and
conditionally authenticates with AWS and Docker registries to reliably
pull required container images while improving security.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
We often get errors while starting the local supabase instance on CI. We
added diagnostics but they are targeting the wrong port.
## Solution
Fix the diagnostics logs
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Granted additional CI credentials and added cloud role assumption plus
container registry login before running self‑hosted end-to-end tests.
* Improved workflow diagnostics to check an alternate local database
port (54322) and show clearer messages when the service is not
listening.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Two-part fix for the Update JS Client Libraries Docs workflow. First,
the `make` invocation was narrowed to `make download.tsdoc.v2` so the
workflow no longer re-downloads unrelated Management and Storage REST
openapi specs alongside the JS TypeDoc files, which was the source of
the noise in #46738. Second, the `build-reference-content` snapshot test
now serializes to a JSON file via `toMatchFileSnapshot` with a
cycle-breaker, because the previous `toMatchSnapshot` of a raw object
was being collapsed to `[Object]` placeholders by pretty-format (533 of
them), hiding every param rename, JSDoc edit, return-type change, and
signature tweak. Verified against supabase-js v2.108.0: the `count` to
`rows` rename in `PostgrestTransformBuilder.{limit,maxAffected}` now
shows up in the snapshot diff as expected.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated documentation generation workflow to run a more targeted build
command.
* Added ignore rule for test snapshot files and refreshed the
autogenerated PR description/reference snapshot.
* **Tests**
* Improved test snapshot strategy to use file-based snapshots and robust
handling of circular structures for more reliable assertions.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
The `Update JS Client Libraries Docs` workflow's "Refresh
reference-content snapshot" step fails because `npx vitest run --update
scripts/build-reference-content.test.ts` is treated as a filter, not a
restriction, under Vitest 4, so all docs tests
run. `CodeSample.test.ts` then fails with ENOENT on
`apps/docs/examples/_internal/fixtures/*` because the workflow bypasses
the `pretest` npm hook that runs `codegen:examples`.
This is a regression of #44943 (commit 28ef62cf31), reintroduced by
#46163 when the snapshot step was renamed and rewritten back to the
file-path form.
Fixes:
- Workflow: use `--dir scripts` so only the snapshot test runs.
- Tests: add a vitest globalSetup that mirrors `codegen:examples`, so
`npx vitest`, `pnpm test:local`, and IDE single-test runs no longer
depend on the `pretest` lifecycle hook being triggered first.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated test infrastructure configuration and initialization process
for improved test suite management.
* Refined test execution workflow to efficiently manage test discovery
and execution across project directories.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
# Second try of making a new better process for SDK automation
Instead of building a new pipeline. We will take the lessons learned
form round 1, plus the good design and improvement on DX quality for
drop-in file as a single step required from SDK team and produce almost
identical set of files as used right now to render using the current
pipeline.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* New reference-content pipeline producing per-library reference
artifacts and integrating into prebuilds, search ingestion, and
rendering (type-aware examples).
* **Documentation**
* Added comprehensive JavaScript SDK v2 reference content and partials
(Auth MFA, passkeys, admin, TypeScript support, filters, modifiers,
Installing, Initializing, Buckets, etc.).
* **Tests & CI**
* Added regression snapshot test and updated workflows to refresh
reference snapshots and ensure spec downloads.
* **Chores**
* Updated ignore rules, build scripts, Makefile targets, and package
lifecycle hooks.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Katerina Skroumpelou <mandarini@users.noreply.github.com>
Co-authored-by: Katerina Skroumpelou <sk.katherine@gmail.com>
## 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?
Bug fix (CI workflow).
## What is the current behavior?
The weekly `Decrease studio lint ratchet baselines` workflow fails on
`git push` with:
```
fatal: could not read Username for 'https://github.com': No such device or address
Error: Process completed with exit code 128.
```
`actions/checkout` runs with `persist-credentials: false`, so no auth is
stored for git. The job generates a GitHub App token but never wires it
into git, so the push has no credentials.
## What is the new behavior?
Push to an explicit token URL using the already-available `GH_TOKEN`,
matching the pattern in `.github/workflows/autofix_linters.yml`. The
force-push to `bot/decrease-eslint-ratchet-baselines` now authenticates
correctly.
## Additional context
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated GitHub Actions workflow configuration to improve automated
process reliability.
**Note:** This release contains no user-facing changes. The updates are
internal infrastructure improvements.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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?
CI / tooling — GitHub Actions workflow update.
## What is the current behavior?
PRs that modify `packages/api-types/types/**` can be merged before the
corresponding API has shipped to production, breaking the Studio
frontend when it calls endpoints that do not exist yet. The
`api-deploy-required` label is enforced only by convention and code
review, which is easy to miss.
## What is the new behavior?
- `.github/labeler.yml`: auto-applies `api-deploy-required` to any PR
that touches `packages/api-types/types/**`.
- `.github/workflows/label_prs.yml`: drops the `apps/docs/**/*` path
filter so the labeler runs on all PRs, and posts a one-time comment when
`api-deploy-required` is newly added (uses the labeler's `new-labels`
output so re-pushes do not re-comment).
- `.github/workflows/validate-pr.yml`: adds a step that fails the
`Validate pull request` check while the `api-deploy-required` label is
present, mirroring the existing `do-not-merge` pattern. The author
removes the label after confirming the API is live to unblock merge.
Reviewer: please confirm `Validate pull request` is configured as a
required check on `master` in branch protection — that step is what
enforces the block.
## Additional context
Resolves FE-3479
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Enhanced pull request automation with improved labeling rules for
API-related changes.
* Added validation that blocks pull request merging until API deployment
is confirmed for changes affecting API types.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46482?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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?
Refactor / chore.
## What is the current behavior?
A custom type-aware ESLint rule (`studio/require-safe-sql-fragment`)
enforces that the `sql` argument to `executeSql` is a `SafeSqlFragment`.
It runs in a separate `eslint.type-checks.config.cjs` and a dedicated CI
ratchet step, and pulls in `@typescript-eslint/utils` as a direct dev
dependency.
## What is the new behavior?
`SafeSqlFragment` enforcement is now handled entirely by TypeScript
compilation. The ESLint rule, its dedicated config, the ratchet
baselines for it, the CI step, and the `@typescript-eslint/utils` direct
dev dependency have all been removed.
## Additional context
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Simplified development linting workflow by removing type-aware ESLint
checks and associated rule files.
* Cleaned up ESLint configuration and dependencies in the studio
application.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46079?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Out of an abundance of caution, running the format step in a strictly
read-only context.
Added explicit validations on pushes instead of relying on an implicit
lack of pull_request_target
Resolves PRODSEC-118
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Reworked automated autofix workflow into a two-step format-and-apply
flow, reduced top-level permissions, and moved from an auto-commit
action to a manual apply/commit/push process for more controlled
automated fixes.
* No user-facing features or functionality changed.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46090?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)
<!-- review_stack_entry_end -->
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
We run the e2e tests across two shards to reduce their duration.
However, one takes longer than the other.
## Solution
Use a currently hidden Playwright feature to balance their load
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Upgraded Playwright test dependency to a newer version for refreshed
test tooling and fixes.
* Adjusted end-to-end test shard weighting to rebalance distribution
across parallel runs.
* **Tests**
* Stabilized several end-to-end editor interactions to make E2E flows
more reliable.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
The Supabase CLI sometimes fails to start because the postgres port is
already used:
> failed to start docker container: Error response from daemon: failed
to set up container networking: driver failed programming external
connectivity on endpoint supabase_db_supabase
(10587f26e7287c8086fd27db12be7aac4afe1f3fc521c9d7a8dfe109993c995d):
failed to bind host port for 0.0.0.0:54322:172.18.0.2:5432/tcp: address
already in use
## Solution
None yet, debugging
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Enhanced end-to-end test workflow with added pre-start and failure
diagnostics for better observability and troubleshooting of test runs.
* Updated the e2e setup CLI script to skip certain local services by
default and clarify script formatting for maintainability.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Vitest 4 no longer restricts test execution when a file path is passed
as a positional filter, causing all docs tests to run and fail on
unrelated tests. Use --dir to scope to the target directory. PR #44833
made the update which broke the behaviour.
* Add `@supabase/ssr` to catalog
* Use `catalog:` version of `@supabase/ssr` across repo
* Add workflow to update `@supabase/ssr`
* Switch runners for package and docs updates to `ubuntu-latest` (free,
lighter)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Centralized `@supabase/ssr` versioning across the workspace via the
package catalog.
* Updated CI workflow runners to a more consistent execution
environment.
* Added an automated workflow to streamline updating the `@supabase/ssr`
package and refreshing dependency lockfiles.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
We are currently migrating to the safeSql utility for all SQL arguments
of executeSql. During the migration, executeSql will continue to accept
plain strings for backwards compatibility. Adding a custom ESLint rule
so we can ratchet this and prevent new calls of executeSql with plain
strings.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added SQL safety validation throughout the application to enforce
secure query construction and prevent SQL-related vulnerabilities
* Introduced type-aware linting to identify and catch type-related
issues during development and continuous integration processes
* **Chores**
* Enhanced continuous integration pipeline with improved code quality
enforcement
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Summary
- Adds a new GitHub Actions workflow that sends a Slack alert when
Studio E2E tests or unit tests fail on master
- Uses `workflow_run` trigger so no changes needed to existing CI
workflows
- Reuses the existing `SLACK_DASHBOARD_WEBHOOK_URL` secret
Closes FE-2883
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Implemented automated Slack notifications to alert when master branch
build failures occur, including build run details, commit information,
and commit author.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Include release notes in the automated PR that updates supabase-js
across the repo.
* Looks at what version is installed
* It includes all changelogs between installed version and
to-be-installed version
## 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?
chore
## Additional context
We will require all actions to be pinned going forward
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated CI/CD workflows to use pinned action versions for improved
reliability and consistency.
<sub>✏️ Tip: You can customize this high-level summary in your review
settings.</sub>
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
The [`docs-mgmt-api-update`
workflow](https://github.com/supabase/supabase/blob/master/.github/workflows/docs-mgmt-api-update.yml#L21)
uses `sparse-checkout`, only pulling `apps/docs` and patches. After PR
#42987, the Makefile's `redocly` commands were changed to run via `pnpm
exec` `redocly` from `packages/generator`, but that directory was never
checked out, causing the can't `cd` error. Adding `packages/generator`
to `sparse-checkout` makes the existing Makefile dependency explicit in
the workflow.
This PR fixes some prettier issues:
- Bump and unify all prettier versions to 3.7.3 across teh whole repo
- Bump the SQL prettier plugin
- When running `test:prettier`, check `mdx` files also
- Run the new prettier format on all files
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## 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?
GitHub action permissions have changed, so because of that We need to
apply permissions on the parent
## Problem
Since the upgrade to NextJS 16.1.6, many e2e tests run fails with
timeout, probably when building or starting the studio
## Solution
- [x] Add dedicated steps for supabase setup and NextJS build to ease
debugging
- [x] Fix flakyness
## 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?
Our runners is running out of memory and CPU when running the build.
Just trying to bump up the blacksmith runner so they match the build
machine in Vercel.
## Problem
The docker build for studio fails because pnpm patches are not included
## Solution
- bump pnpm version in Dockefile to match the one used by the repo
- bump turbo version in Dockerfile to use one that handles pnpm patches
- add a script to test the build locally
- add a github action to validate the build on each PR
Lays groundwork for online evals on Assistant chat logs.
https://www.braintrust.dev/docs/observe/score-online
### Changes
- New workflows:
- `braintrust-scorers-deploy.yml` keeps prod scorers in sync on push to
`master`
- `braintrust-preview-scorers-deploy.yml` deploys preview scorers to the
staging project for PRs labeled `preview-scorers`, posting a comment
with scorer links
([example](https://github.com/supabase/supabase/pull/43194#issuecomment-4000097222))
- `braintrust-preview-scorers-cleanup.yml` deletes preview scorers when
the PR is closed
([example](https://github.com/supabase/supabase/pull/43194#issuecomment-4000749847))
- Adds `evals/scorer-online.ts` entry point invoked with `pnpm
scorers:deploy`, registering scorers for online evals in the Braintrust
"Assistant" project
- Refactors scorer code to separate online-compatible scorers
(`scorer-online.ts`) from WASM-dependent ones (`scorer-wasm.ts`)
- "URL Validity" scorer now only checks Supabase domains to prevent
requests to untrusted origins
- Span `input` is now shaped `{ prompt: string }` instead of plain
`string` for compatibility with offline eval scorers
- Env vars `BRAINTRUST_STAGING_PROJECT_ID` and `BRAINTRUST_PROJECT_ID`
configured in GitHub repo settings
- `generateAssistantResponse` now uses `startSpan` + `withCurrent`
instead of `traced()` to manually manage the root span lifecycle — this
ensures `onFinish` logs output to the span _before_ `span.end()` is
called, which is when Braintrust triggers scoring automations
### Online Scorers
We share scoring logic across offline and online evals, but some of our
scorers aren't transferrable to an "online" setting due to runtime
challenges or ground truth requirements.
**Supported**
- Goal Completion
- Conciseness
- Completeness
- Docs Faithfulness
- URL Validity
**Unsupported**
- Correctness (requires ground truth output)
- Tool Usage (requires ground truth requiredTools)
- SQL Syntax (uses libpg-query WASM)
- SQL Identifier Quoting (uses libpg-query WASM)
### How to use these scorers
Going forward if you want to add/edit online eval scorers, add the
`preview-scorers` label to a PR. This deploys scorers to the [Assistant
(Staging
Scorers)](https://www.braintrust.dev/app/supabase.io/p/Assistant%20(Staging%20Scorers)?v=Overview)
project in Braintrust with branch-specific slugs, and comments on the PR
([example](https://github.com/supabase/supabase/pull/43194#issuecomment-4000097222)).
From the Braintrust dashboard you can "Test" the scorer with traces from
any project.
<img width="1866" height="528" alt="CleanShot 2026-03-05 at 15 15 00@2x"
src="https://github.com/user-attachments/assets/4f15cebc-3f2d-4e8a-9ee2-fe8ef7bf4199"
/>
Once merged, scorers are deployed to the primary
[Assistant](https://www.braintrust.dev/app/supabase.io/p/Assistant)
project, and preview scorers are deleted from the staging project. Down
the road, scorers on the Assistant project will run automatically on a
sample of production traces.
Closes AI-437
## Problem
e2e tests are still flaky and not as fast as they could be
## Solution
- [x] Reset supabase instance: this makes the database visualiser tests
faster as there are less tables to screenshot
- [x] Improve the single file setup utilities so that they never block
local tests by cleaning them up before starting
- [x] Disable animations while running the tests (less time waiting for
animations to complete
- [x] Add utility functions that help reproducing flaky tests locally
## Problem
On Safari, it's impossible to resize a column.
## Solution
This is actually a bug in `react-data-grid` that has been fixed in more
recent versions but we can't use them.
Patch the package
## How to test
- Open the any table in the _Table editor_
- Resize a column
