## 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?
Database migration — adds a table for collecting free-form product
feedback submitted from Supabase interfaces (starting with the CLI and
the MCP server), including support for deleting a submission via a
server-issued token.
## What is the current behavior?
There is no destination for feedback submitted from the CLI or MCP
server. The existing `feedback` and `feedback_comments` tables are
scoped to the docs feedback widget, so interface feedback would
otherwise end up as ad-hoc GitHub issues — with no way to revoke
something submitted by accident (e.g. a secret key pasted into the
message).
## What is the new behavior?
Adds `public.interfaces_feedback`:
| Column | Type | Notes |
| --- | --- | --- |
| `id` | `bigint` identity | primary key (not exposed through the API) |
| `created_at` | `timestamptz` | `not null default now()` |
| `feedback` | `text` | `not null`, ≤ 1000 chars — the free-form
feedback |
| `delete_token` | `uuid` | server-generated, `unique not null`;
authorizes deleting the row |
| `user_agent` | `text` | ≤ 255 chars; interface + version, also
identifies the source interface |
| `user_id` | `text` | optional, ≤ 255 chars; unverified,
interface-defined identifier |
| `project_ref` | `text` | optional, ≤ 255 chars |
| `metadata` | `jsonb` | ≤ 8 KB catch-all |
**Submission** happens exclusively through a `SECURITY DEFINER`
function, `submit_interfaces_feedback(...)`, which inserts the row and
returns the server-generated `delete_token` exactly once. There is no
insert grant or policy on the table itself, so clients cannot insert
directly or supply their own token — the function is the only door.
Execute is revoked from `PUBLIC` and granted to `anon` only (both
statements matter: local and hosted databases have different default
function ACLs).
**Deletion** is a hard `DELETE` authorized by presenting the token in an
`x-feedback-token` request header. RLS policies compare the row's
`delete_token` against that header (`current_setting('request.headers',
...)`) — the URL filter is never the security boundary; a request
without the matching header affects zero rows, even with no filter or
someone else's token in the filter. Tokens never expire (the delete
right shouldn't lapse). The header is cast to `uuid` and compared
against the untransformed column, so lookups use the unique index on
`delete_token` even for header-only reads; a malformed token header is
rejected with a `400` (`22P02`), consistent with what a malformed URL
filter value already returns.
**Context gate (defense-in-depth)**: rows submitted with a `project_ref`
and/or `user_id` additionally require the matching
`x-feedback-project-ref` / `x-feedback-user-id` headers — on both reads
and deletes — so a leaked bare token can neither read the submission
text back nor remove the row. A `NULL` column imposes no requirement:
context-free rows keep token-only behavior, and extra headers sent
against them are ignored (this keeps clients that always send their
current context from being locked out of rows submitted without it).
These are client-supplied, unverified values, so the gate is a knowledge
factor rather than an identity check; clients should persist
`{delete_token, project_ref, user_id}` together at submit time and
re-present them byte-exact (`project_ref`/`user_id` are compared as
plain text).
**Reads** are limited to `grant select (feedback, delete_token)` behind
the same token-scoped policy: a token-holder can preview their own
submission text before deleting and confirm the delete matched (`Prefer:
count=exact` → `Content-Range: */1` vs `*/0`). No other columns are
readable by any API role; `delete_token` needs select because PostgREST
requires a WHERE clause on deletes and filter columns require select
privilege.
Verified locally via `supabase db reset` + the local REST API: token
issuance, token-scoped preview and delete, zero-row results for
missing/wrong/malformed tokens (including a victim's token in the filter
without the header), the full context-gate matrix (project+user,
project-only, and context-free rows, incl. lenient extra-header
behavior), denied direct inserts and column reads, length caps enforced
through the function, and no execute for `authenticated`.
## Additional context
Linear tickets: [CLI-1946](https://linear.app/supabase/issue/CLI-1946),
[CLI-1999](https://linear.app/supabase/issue/CLI-1999)
The client-side flows (`supabase feedback add` / `feedback delete` in
the CLI, and the MCP tool) land separately in their respective repos and
will call the RPC / DELETE endpoint described above.
Supersedes #48378 — recreated on a fresh git branch so that the Supabase
preview branch used for testing this table isn't shared with unrelated
work.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added support for collecting and storing feedback submitted through
interfaces.
* Feedback can include submission source, timestamps, user details,
project references, and additional metadata.
* Added secure feedback submission with controlled access to protect
submitted information.
* Added support for authorized feedback removal using a secure deletion
token.
* Added safeguards to validate feedback content and restrict access to
permitted information.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
## Details of change
Re-lands DATAENG-1468 (docs page feedback to Postgres) with an
**insert-only** design that avoids the cross-project auth issue that
caused the prior revert.
- New insert-only `feedback_comments` table: anon `insert` policy only
(no select/update/delete). Columns: `page`, `vote`, `title`, `comment`,
`user_id`, `metadata`.
- The docs widget writes the free-text comment to `feedback_comments`
via the **anon key**. The votes `feedback` table is untouched (one row
per vote).
- No user token is sent to the content project anymore (that was the
cause of the previous failure): the feedback client uses the anon key
only.
- The commenter's account user id (gotrue UUID) is read client-side from
the session and stored as a plain `user_id` column for attribution
(comments are logged-in-only). Org/project association is derived
downstream in BigQuery via that id; docs pages aren't project-scoped, so
there's no project_ref/org to capture here.
- Removed the previous update-by-id approach, the per-user RLS policies,
and the obsolete unit test.
## Why the previous version was reverted
It authenticated feedback writes with the supabase.com account session
token, but the requests target the docs content project
(`xguihxuzqibwxjnimxev`), which cannot verify that token. Logged-in
users got `PGRST301 / JWSInvalidSignature`. This version removes the
user token entirely, so writes succeed for everyone.
## Verification
Insert-only RLS means a row can be written but not read/updated/deleted
by `anon`. Comments retrievable with `where comment is not null` is not
needed (separate table); just query `feedback_comments`.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* The feedback form now captures a vote rating along with an optional
title and detailed comments, saving richer context for review.
* **Refactor**
* Feedback submission has been streamlined to write directly to the
database for both vote and comment submissions.
* **Maintenance**
* Updated the feedback data typings to support the new title, comment,
user, page, and vote fields via the new feedback comments storage.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Reverts supabase/supabase#46941
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **New Features**
* Feedback is now automatically routed to the appropriate documentation
team based on the section being viewed.
* **Improvements**
* Streamlined feedback submission process—votes and comments are now
collected more efficiently in a single submission.
* Enhanced feedback data handling and organization for better team
collaboration.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What
- Route docs page feedback **comments** to Postgres instead of `POST
/platform/feedback/docs` (which created duplicate Linear issues); the
👍/👎 vote is unchanged
- Store the comment on the **existing `feedback` row**: add `user_id` /
`title` / `comment`; submitting a comment updates the vote row the user
just created
- Capture the real `user_id` (`default auth.uid()`) so feedback is tied
to the user
- Owner-scoped RLS — `select`/`update` for authenticated users where
`user_id = auth.uid()`; anonymous votes stay insert-only
- Linear issues still get created, now via the data pipeline instead of
directly from the UI
## Linear
[DATAENG-1468](https://linear.app/supabase/issue/DATAENG-1468)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Feedback follow-ups now support saving a detailed title and comment,
tied to the signed-in user.
* **Bug Fixes**
* Follow-up submissions are now persisted in Supabase, ensuring the vote
and later details stay consistent for logged-in users.
* **Tests**
* Added coverage for updating a feedback entry’s title and comment.
* **Chores**
* Removed the previous feedback submission endpoint/mutation flow in
favor of a Supabase update-based approach.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.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?
Replaces "stored procedures" with "functions" for everything related to
the Data API.
## Additional context
It's not accurate to call database functions "stored procedures". It may
have been that way before Postgres 11, but now it causes confusion
because PostgREST allows functions and not stored procedures.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Standardized terminology across docs, SDK guides, CLI/config specs,
examples, UI, and config comments to use "database functions" instead of
"stored procedures".
* Updated API docs, CLI/config descriptions, Studio UI labels, help
text, empty-state and navigation copy, RPC documentation, and example
text for consistency.
* Adjusted explanatory text and error/help messages to reflect the
revised terminology.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Disabled email-based user signup for the production environment.
* Disabled local database network restrictions to simplify local
development and testing.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Database migration — adds a new table.
## What is the current behavior?
There is no table to cache AI-derived incident metadata.
## What is the new behavior?
Adds an `incident_status_cache` table for caching AI-derived incident
metadata.
Add a Query Performance page implementation powered by
[supamonitor](https://github.com/supabase/supamonitor).
[Context](https://linear.app/supabase/project/build-extension-for-supabase-query-insights-df4fb145352c/overview)
This looks largely the same as the pg_stat_monitor implementation:
<img width="2556" height="960" alt="Screenshot 2026-02-12 at 7 35 47 PM"
src="https://github.com/user-attachments/assets/bf37466e-f7af-41f2-b4f2-cf8eb6a8c76f"
/>
Only available on projects on custom AMI - existing users are unaffected
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Supamonitor-based query performance view: charts, aggregated metrics,
date-range controls, and export/download.
* Added "Application" column for per-application tracking.
* Interactive Supamonitor grid: sorting, filtering, keyboard navigation,
selection, retry/error handling.
* Automatic per-project Supamonitor detection with toggleable UI
integration.
* **Bug Fixes**
* Chart latency calculation prefers histogram data for more accurate
p95.
* **Documentation**
* Minor blog formatting fix.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: kemal <hello@kemal.earth>
Co-authored-by: Ali Waseem <waseema393@gmail.com>
* Use the .sql suffix when generating ids.
* Fix a bug where a new snippet would not show up in the snippet list until refresh.
* Add API routes which serve file snippets.
* Refactor the renameSnippet and moveSnippet to work with file snippets.
* Change the link to the SQL Editor.
* Minor fixes from CodeRabbit.
* Check the file/folder name for invalid chars.
* More fixes from CodeRabbit review.
* Fix minor issues.
* Use zod to parse the snippet ids when deleting.
* Try to fix snyk issue.
* Add validation to the GET content index route.
* Minor fixes.
* Show create a new folder, it was hidden by mistake.
* Add SNIPPETS_MANAGEMENT_FOLDER env var.
* Add snippets folder in the docker-compose.
* Add error toasts if the env var is not set.
* Add snippets management folder to the generateLocalEnv script.
* Revert the docker-compose changes, will be done in a followup PR.
* Revert also the snippets volume folder.
* Remove unneeded line.
* updated commands and expose ai key locally
* added tests for AI assistant
* added OPEN_API_KEY for e2e test suite
* updated log drain options
* updated README
* feat: alternate search index for nimbus
Create an alternate search index for Nimbus that filters out
feature-flagged pages (equivalent to setting all feature flags to
false).
Notes:
- Creates two new DB tables, `page_nimbus` and `page_section_nimbus`,
which are filtered versions of `page` and `page_section`
- Makes `nimbus` versions of all the DB search functions
- Refactored the embedding upload script. Changes to make it faster (got
annoyed by how slow it was when testing...), incorporate retries, and
produce better summary logs.
- Upload script, when run with the environment variable
ENABLED_FEATURES_OVERRIDE_DISABLE_ALL, produces and uploads the
alternate search index
- Changed all the search calls in frontend/API to check for
`isFeatureEnabled('search:fullIndex')` to determine whether to search
the full or alternate index
* ci: produce nimbus search indexes on merge
* fix: turn full search index on
Implement hybrid search for the /docs/api/graphql searchDocs endpoint. Prepend a more descriptive title and introduction to database advisor docs so they rank more highly when directly searched for.
There are a bunch of Edge Functions that are deprecated, removing them
to avoid confusion. Checked the project dashboard to make sure that they
either aren't deployed at all, or there's been no traffic to them in the
last day (the furthest back the view goes).
* feat(graphql): add paginated errors collection query
- Add new GraphQL query field 'errors' with cursor-based pagination
- Add UUID id column to content.error table for cursor pagination
- Implement error collection resolver with forward/backward pagination
- Add comprehensive test suite for pagination functionality
- Update database types and schema to support new error collection
- Add utility functions for handling collection queries and errors
- Add seed data for testing pagination scenarios
This change allows clients to efficiently paginate through error codes using cursor-based pagination, supporting both forward and backward traversal. The implementation follows the Relay connection specification and includes proper error handling and type safety.
* docs(graphql): add comprehensive GraphQL architecture documentation
Add detailed documentation for the docs GraphQL endpoint architecture, including:
- Modular query pattern and folder structure
- Step-by-step guide for creating new top-level queries
- Best practices for error handling, field optimization, and testing
- Code examples for schemas, models, resolvers, and tests
* feat(graphql): add service filtering to errors collection query
Enable filtering error codes by Supabase service in the GraphQL errors collection:
- Add optional service argument to errors query resolver
- Update error model to support service-based filtering in database queries
- Maintain pagination compatibility with service filtering
- Add comprehensive tests for service filtering with and without pagination
* feat(graphql): add service filtering and fix cursor encoding for errors collection
- Add service parameter to errors GraphQL query for filtering by Supabase service
- Implement base64 encoding/decoding for pagination cursors in error resolver
- Fix test cursor encoding to match resolver implementation
- Update GraphQL schema snapshot to reflect new service filter field
* docs(graphql): fix codegen instruction
Add a script for syncing error codes from the repo to the database. This
is part of the newly created rootSync script, where all sync scripts
should be moved eventually.
* feat(content api): add error endpoint
Add an endpoint to return the details of a Supabase error, given the
error code and service.
Schema additions:
```graphql
type RootQueryType {
"...previous root queries"
"""Get the details of an error code returned from a Supabase service"""
error(code: String!, service: Service!): Error
}
"""An error returned by a Supabase service"""
type Error {
"""
The unique code identifying the error. The code is stable, and can be used for string matching during error handling.
"""
code: String!
"""The Supabase service that returns this error."""
service: Service!
"""The HTTP status code returned with this error."""
httpStatusCode: Int
"""
A human-readable message describing the error. The message is not stable, and should not be used for string matching during error handling. Use the code instead.
"""
message: String
}
enum Service {
AUTH
REALTIME
STORAGE
}
```
* test(content api): add tests for top-level query `error`
* feat(db): error table updating function
Add a function for updating the error table (to be used for syncing the
repo contents to the database).
* feat(db): add function to delete unused error codes
Add a DB function to delete any unused error codes (actually a soft
delete due to a rule on the content.error table). This allows syncing
the repo state to the DB state by removing any entries that have been
removed from the repo.
Couple of DB changes to set up for exposing error codes via the API:
- Add a content schema to keep things organized since we'll be syncing
all content to the DB now. This is exposed via the API so it can be
queried via PostgREST.
- Add tables for tracking error codes.
- Add some utility functions for common tasks.
Create index with HNSW fails on prod because it has a version of
pgvector < 0.5.0. Removing for now because the index isn't critical
(we're not using any at the moment and we have few enough rows that it
works fine).
* feat(content api): add client library api reference search results
Allow searchDocs results to also return function references from the
client library APIs
* fix(content api): refine language enum handling
* docs: user nav dropdown
* www: user dropdown nav
* update menus
* chore: add complete local storage allowlist
* move all local-storage to common
* reload after logOut
* add local storage key changes from #35175
* fix errors
* add more keys
* fix merge bugs
---------
Co-authored-by: Alaister Young <a@alaisteryoung.com>
Add some new search functions. Should behave roughly the same as the
search functions that are currently in use, but formatted to work better
for the new search endpoint(s).
Fixes an invalid migration that was preventing other migration files from being pushed on top. The two `alter table` changes are already in prod migration history under this timestamp, but the `comment` change is not, so we should be safe to just delete it and add it in a separate migration.
* lw13 interactive realtime grid
* 3d metal ticket
* add dynamic text to ticket
* reset ticket tilt on mouseout
* improve canvas sizing and ticket positioning and originate tilt from ticket
* test lw layout
* test lw layout
* fix imports
* .
* fix .length bug
* usual ticketing flow
* reduce ticket padding
* reduce fade delay
* add name from db
* text size
* use multiplayer.dev cursor logic
* lodash samplesize
* good state
* working users cursors
* single partyMode off
* clean up
* refactor ticket layout and positioning logic
* regular and platinum tickets
* regular theme based og
* add mono font to ticket, finish textures and ogs
* ticket cleanup
* restore countdown with ticket
* update og
* update og
* remote year add hour
* drag ticket to flip
* remove
* add presence
* remove cursor on own touch device
* test hidden mobile cursor
* fix mobile dragging
* scale ticket on interaction
* code logic
* secret ticket logic
* cleanup
* persist won game
* enable game on mobile
* fix mobile game
* add announcement banners
* update text layout
* hide game from share page and if game won
* fix mobile flip 🎉
* fix meetups time formatting
* faster flip
* tiger init styling (#30649)
* update
* mobile fix
---------
Co-authored-by: Jonathan Summers-Muir <MildTomato@users.noreply.github.com>
* use multilanguage font
* lineheight
* only published meetups
* comment on timezone column
* better mobile input positioning
* fix sudden lighting change
* increase cell size for better performance
* increase cell size for better performance
* last touches
---------
Co-authored-by: Jonathan Summers-Muir <MildTomato@users.noreply.github.com>
Add JSON schema validation for troubleshooting entries, and add columns for storing GitHub discussion metadata.
Also some minor UI tweaks for troubleshooting display.
Add a route for manually revalidating cache contents by tag.
The route is protected by authentication to prevent abuse. Automated
actions in CI should be set up with a basic API key, which has a rate
limit of 6 hours between changes. Overriding is possible with an
override key, which should be used as an escape hatch.
Usage:
- API key provided in header `Authorization: Bearer <KEY>`
- Body has shape `{ tags: string[] }`
Add a DB table for troubleshooting entries. This will be used to support
persistent relationships between GitHub troubleshooting entries and docs
site troubleshooting entries.
Keeps track of fine-grained (per section) edit times for docs content.
Once daily, a GitHub Action runs that:
- Checks whether content hashes have changed for each section
- Updates the table that tracks content edit times if the hashes have changed
Note: The cron job isn't scheduled yet. I'll run the Action manually a few times to validate it, then turn it on in another PR.
kanad