[pull] master from supabase:master#887
Merged
Merged
Conversation
## Description Replaces legacy `anon` / `service_role` key references with the new `publishable` / `secret` naming across SDK spec files under `apps/docs/spec/`. Mirrors the rename table established by [supabase-js#2280](supabase/supabase-js#2280), so the auto-generated reference docs at supabase.com/docs/reference/{js,dart,kotlin,python,swift} stay consistent with the SDK source. ## Files changed | File | Highlights | | --- | --- | | `supabase_js_v2.yml` | Rename example vars `anon_key` → `publishable_key`, `service_role_key` → `secret_key`; admin notes use `secret`. | | `supabase_dart_v2.yml` | Rename `anonKey` param → `publishableKey` (matches the live Flutter SDK — see [supabase-flutter/supabase.dart#L81](https://github.com/supabase/supabase-flutter/blob/main/packages/supabase_flutter/lib/src/supabase.dart#L81)); update call-site; example var `serviceRoleKey` → `secretKey`; admin notes use `secret`. | | `supabase_kt_v2.yml`, `supabase_kt_v3.yml` | Replace `'publishable-or-anon-key'` placeholders with `'your-publishable-key'`; admin notes use `secret`; fix `importAuthToken(\"service_role\")` → `importAuthToken(\"your-secret-key\")` (the Kotlin SDK's `importAuthToken(accessToken: String, …)` takes a JWT, not a role name). | | `supabase_py_v2.yml` | All `service_role` references → `secret`; example var `service_role_key` → `secret_key`. | | `supabase_swift_v2.yml` | Replace placeholders with `'your-publishable-key'`; admin notes use `secret`; example var `serviceRoleKey` → `secretKey`. | | `storage_v0_config.yaml` | Rewrite `ANON_KEY` / `SERVICE_KEY` env var **descriptions** in publishable/secret terms. **Env var names kept** — see below. | ## Why the storage env var names are unchanged `storage_v0_config.yaml` documents the env vars used to configure the storage server (multi-tenant deployments). The `id` and `title` fields must match the actual env var names the binary reads. The storage server still reads its config from env vars literally named `ANON_KEY` and `SERVICE_KEY`: - [`storage/src/config.ts#L614`](https://github.com/supabase/storage/blob/master/src/config.ts#L614) — `getOptionalConfigFromEnv('SERVICE_KEY')` - [`storage/src/config.ts#L625`](https://github.com/supabase/storage/blob/master/src/config.ts#L625) — `getOptionalConfigFromEnv('ANON_KEY')` There is no `PUBLISHABLE_KEY` / `SECRET_KEY` reader on master. Renaming the doc IDs would break self-hosted deployments — users following the docs would set the wrong env var and the storage server would silently fall back to generating its own JWT. Until the storage server itself adds publishable/secret env support, only descriptions can be updated. (Same reasoning for not bumping `storage_v0_config.yaml` → `storage_v1_config.yaml`: the `_v0_` tracks the storage server's own API version, paired with `storage_v0_openapi.json` downloaded from `supabase.github.io/storage/api.json`. The server hasn't shipped a v1 API.) ## What we deliberately did NOT rename Per the same rules established in supabase-js#2280: - **JWT role claims** like `role: 'anon'` / `role: 'service_role'` — these are functional Postgres role names in JWT payloads, not key labels. - **Real SDK identifiers** that haven't been renamed in the source (we only rename in the doc when the underlying SDK rename has shipped). The Dart `anonKey` rename was safe to apply because the Flutter SDK already ships `publishableKey` as the preferred named parameter (with `anonKey` `@Deprecated`). ## Out of scope - **All `*_v1.yml` SDK spec files** (`supabase_js_v1`, `supabase_dart_v1`, `supabase_kt_v1`, `supabase_swift_v1`). Older SDK versions, not worth churning. - **`cli_v1_commands.yaml`**. This file is auto-generated by the CLI repo's release workflow ([`cli/tools/bumpdoc/main.go`](https://github.com/supabase/cli/blob/develop/tools/bumpdoc/main.go)) and the example outputs come from [`cli/docs/templates/examples.yaml`](https://github.com/supabase/cli/blob/develop/docs/templates/examples.yaml) — embedded in the CLI binary at build time. Any edits we make here would be clobbered by the next CLI release. The fix needs to land upstream in the CLI repo (note: the CLI itself already ships publishable/secret naming in \`supabase status\` output — see [`cli/internal/status/status.go#L40-L44`](https://github.com/supabase/cli/blob/develop/internal/status/status.go#L40-L44) — but the doc-generation template is stale). - **`supabase_csharp_v0.yml` / `supabase_csharp_v1.yml`** — checked, already neutral. Both files use a generic `SUPABASE_KEY` env var with no `anon` / `service_role` references. - **Renaming the legacy Dart `anonKey` parameter itself** — that's an SDK-side change. The Flutter SDK already exposes `publishableKey` as the preferred parameter; full removal of `anonKey` will happen in a future major version per the SDK's own deprecation comment. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Standardized API key naming across SDK docs: use publishable (client) and secret (server/admin) key terminology * Updated server-side admin examples and warnings to require secret keys and emphasize never exposing them in client code * Unified initialization examples across JavaScript, Dart, Kotlin, Python, and Swift * Corrected Storage spec metadata to point to the proper configuration file <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
## Context Just happened to pass by this - refactor to use Admonition instead of Alert + fix spacing + use InlineLink e.g General settings while on a preview branch ### Before <img width="795" height="364" alt="image" src="https://github.com/user-attachments/assets/28ab66ab-bd10-408e-afb5-24e287efc705" /> ### After <img width="759" height="349" alt="image" src="https://github.com/user-attachments/assets/db62925d-f2e2-4c10-9cab-ce8204f2077c" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Style** * Preview-branch notices across Settings now use a unified admonition design with adjusted spacing for improved visual consistency. * **Refactor** * Standardized branch-notice layout and inline navigation links across Addons, General, and Integrations; each notice now links directly to its respective settings page for clearer navigation. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
…45493) The SQL Editor was warning about missing RLS even when the same query enabled it, if the user wrote `ALTER TABLE IF EXISTS ...`. The parser regex didn't recognise `IF EXISTS` and was capturing `IF` as the table name, so the RLS event never matched the `CREATE TABLE`. **Changed:** - `ALTER TABLE` regex in `sql-event-parser.ts` now accepts the optional `IF EXISTS` and `ONLY` modifiers, matching Postgres's `ALTER TABLE [ IF EXISTS ] [ ONLY ] name` grammar. **Added:** - Unit tests for `IF EXISTS`, `ONLY`, and both combined. - Regression test in `SQLEditor.utils.test.ts` using the customer's exact SQL. ## To test 1. Open the SQL Editor and paste: ```sql CREATE TABLE IF NOT EXISTS public."Conversations" (id int8 primary key); ALTER TABLE IF EXISTS public."Conversations" ENABLE ROW LEVEL SECURITY; ``` 2. Hit Run – the "table will not have RLS" warning should **not** appear. 3. Sanity check: a `CREATE TABLE` without any matching `ENABLE ROW LEVEL SECURITY` still triggers the warning. Addresses [FE-3134](https://linear.app/supabase/issue/FE-3134/sql-editor-warns-about-missing-rls-policy-incorrectly). <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Tests** * Added comprehensive test coverage for Row Level Security detection across different SQL syntax patterns and clause combinations * **Bug Fixes** * Enhanced Row Level Security detection capabilities in the SQL editor by extending support for additional ALTER TABLE statement syntax variations, improving the accuracy and completeness of security configuration recognition <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
## Before <img width="626" height="176" alt="image" src="https://github.com/user-attachments/assets/02db6dd4-aaba-4e3a-8073-52661bbd9058" /> ## After <img width="524" height="157" alt="image" src="https://github.com/user-attachments/assets/cdecb26d-1d51-444f-97df-23681bb84792" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Style** * Adjusted the layout of the feature preview badge on the merge page. * Updated text capitalization in the merge confirmation dialog. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
…container (#45510) ## Problem The Database tables filter has a smaller tap-target than its visual container. This was probably introduced when we added the Shadcn `input-group`. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Style** * Updated internal styling implementation for improved code maintainability. --- **Note:** This is a minor internal refactor with no visible changes to user-facing functionality. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem The Max IOPS reference line in the Database Observability report displays the provisioned disk IOPS, but its tooltip claims it shows the "Maximum IOPS for your current compute size". The real effective ceiling is `min(compute IOPS limit, provisioned disk IOPS)`. Users who upgrade their disk IOPS without upgrading compute see an inflated number and may draw incorrect conclusions about their IO headroom. Reported in [Linear DEBUG-63](https://linear.app/supabase/issue/DEBUG-63) (originally [FE-2856](https://linear.app/supabase/issue/FE-2856)). ## Fix In [apps/studio/data/reports/database-charts.ts](apps/studio/data/reports/database-charts.ts), use the existing `mapComputeSizeNameToAddonVariantId` + `COMPUTE_MAX_IOPS` lookup (already used in DiskManagement) to compute the effective ceiling and pass it as the `disk_iops_max` reference line value. Tooltip rewritten to match. ```ts const provisionedDiskIops = diskConfig?.attributes?.iops const computeIopsLimit = COMPUTE_MAX_IOPS[mapComputeSizeNameToAddonVariantId(project?.infra_compute_size)] const effectiveMaxIops = typeof provisionedDiskIops === 'number' && typeof computeIopsLimit === 'number' ? Math.min(provisionedDiskIops, computeIopsLimit) : provisionedDiskIops ``` ## Test plan - [ ] On a project where compute IOPS limit < provisioned disk IOPS (e.g. Micro compute with upgraded disk), confirm the Max IOPS reference line on `/project/{ref}/observability/database` reflects the compute limit, not the disk IOPS. - [ ] On a project where provisioned disk IOPS < compute IOPS limit, confirm the reference line still shows the disk IOPS. - [ ] Hover the line and confirm the tooltip reads "Effective maximum IOPS for your current compute and disk configuration..." 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **Bug Fixes** * Enhanced IOPS limit calculations in database reports to account for both compute size and disk provisioning constraints, resulting in more accurate Max IOPS reference values. Improved chart tooltips to better reflect the effective combined compute and disk IOPS constraints. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
<!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated UI labels and descriptions across the Data API settings to clarify that default privileges apply to new tables only (removed references to functions). <!-- end of auto-generated comment: release notes by coderabbit.ai -->
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.
6 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 : )