The AuthorizeResult union and its guards were never wired into the approve
flow, so knip reported the file as dead. Reintroduce it alongside the error
state that uses it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adds re-consent support (`existing_grant`), a provisional
`role_validation_failed` result member, and moves member roles onto
individual projects.
BREAKING CHANGES for downstream branches:
- Approve mutation signature and return shape. It now takes
`{ slug, auth_id, project_refs }` and validates that `project_refs` is
non-empty. No selection cap is enforced here: that is a UI and backend
concern and the limit is expected to change. Both redirects now carry a
`state` param alongside `code` / `error`. The deny mutation takes
`{ slug, auth_id }` for symmetry.
- Projects carry a `ref`. Selection submits refs, not names or ids.
- Roles moved from identity level to per project. Organizations expose
`default_role`; each project carries the member's `role`, which overrides
it. Mock project roles are deliberately heterogeneous within one org.
The re-consent fixture is deliberately poisoned: one granted ref no longer
resolves against the live project list, and its approved scopes differ from
what the app requests today.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Rename the placeholder org from some-other-org to contoso-labs and swap
the mock identity emails for admin@example.com.
Also guard the exported authorize query fetchers behind USE_MOCKS, matching
the approve/deny mutations. The hooks already gated via `enabled`, but the
fetchers returned mock data when called directly.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
approveOAuthAppsAuthorize and denyOAuthAppsAuthorize called the mock
redirect helper unconditionally, unlike every query hook in this
domain which gates on USE_MOCKS. In a production build this would
silently return a fake mock_authorization_code redirect instead of
failing - fail explicitly instead until the real endpoints exist.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Andy Burnham is a real public figure; swap the fixture for a
non-controversial, classic placeholder company name instead.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
I made the connected-project framework icons fall back when no shipped
SVG exists for a framework. The three icon sites built
`/img/icons/frameworks/<framework>.svg` straight from the integration's
framework preset, which is an open-ended string. They only fell back
when the value was empty, so any preset without an asset (`express`,
`hono`, `fastapi`, `tanstack-start` and others) showed a broken image
and logged a 404.
**Changed:**
- **Broken framework icons**: `getFrameworkIconUrl` returns the asset
URL only for slugs in a set that mirrors `public/img/icons/frameworks/`.
The integration connection row, the org project linker and the
marketplace project picker now show their existing fallback icon for any
other slug. A test keeps the set equal to the directory listing.
- **Framework type**: I deleted the hand-kept `VercelFramework` union.
It listed exactly the shipped icon slugs, while the API types the field
as `string | null`, and that mismatch is what made the old empty-only
check look safe.
**Note:** I rejected an `onError` fallback because the browser still
sends the 404 request. Adding logos for common presets is left for
design.
## To test
Tested on Vercel preview (staging): no real connection there uses these
presets, so I rewrote the org integrations response in the browser to
give one integration four connections.
- [x] Open an org's Integrations page with connections whose framework
has no shipped icon (`express`, `eve`, `tanstack-start-lovable`). Expect
the fallback badge and no request under
`/dashboard/img/icons/frameworks/` for those slugs. Observed: all three
rows showed the badge and the network log had no request for their SVGs.
- [x] Same page with a `nextjs` connection. Expect its framework logo.
Observed: `nextjs.svg` loaded with a 200.
- [x] Same page with the real, unmodified response (one connection with
`framework: null`). Expect the badge, no frameworks requests, and no new
console errors. Observed: as expected.
## Linear
- fixes GROWTH-1309
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Vercel integration and project views now display framework icons when
available and fall back to the Vercel icon when no matching icon exists.
* Framework metadata now supports values beyond a fixed list, while
unsupported frameworks continue to use the fallback icon.
* **Tests**
* Added coverage for supported and unsupported framework icons,
including base-path handling.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Summary
- Extracts `useUserProjectRegions` (org + project region aggregation,
fail-open on fetch errors) and `useEmergencyIncidentOverride` (the
`ongoingIncident` flag / env var check) out of
`useStatusPageBannerVisibility`, so the upcoming incident.io status-page
banner can reuse both without duplicating the org/project fan-out logic.
- No behavior change for the legacy banner except one intentional fix:
`StatusPageBanner.utils.ts` compared the incident's affected regions
(lowercased) against the user's regions (not normalized), so a
mixed-case region on either side could silently fail to match. Both
sides now go through the same `normalizeRegion` helper.
- Part of the Linear FE-4057 stack (PR 5a of 6). Base branch is PR 4
(`charis/fe-4057-pr4-project-creation-status-admonition`), not master.
Linear: FE-4057
## Test plan
- [x] `pnpm --filter studio run typecheck`
- [x] `pnpm --filter studio run lint:ratchet`
- [x] `pnpm knip --workspace apps/studio`
- [x] `pnpm test:prettier`
- [x] `pnpm --filter studio exec vitest run` on the touched test files
and the `hooks/misc/` and `components/layouts/AppLayout/` directories
(all passing, no regressions)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved status banner targeting by matching incidents against
normalized regions across the user’s projects.
* Updated banner visibility checks to handle incomplete project or
region data, including when project information fails to load.
* Improved loading behavior so the banner can be evaluated based on
user-region data rather than waiting for separate organization and
project requests.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
I added outcome events for Explorer query runs and successful manual
notebook saves. Existing page visits and preview toggles do not show
whether users complete queries or persist notebooks.
**Changed:**
- **Query usage:** Accepted runs from query tabs and notebook cells emit
submitted and terminal outcome events with a shared run ID. Canceled
confirmations emit no run events.
- **Notebook adoption:** Successful manual saves emit created or updated
events. Recreated notebooks count as creations. Unsaved drafts and
failed saves emit neither.
- **Event metadata:** Explorer action events use `Explorer` as their
page title.
**Note:** Assistant-generated saves are outside this PR. Custom
properties omit SQL and notebook content. Page visits still carry the
browser title, which can include a notebook name.
## To test
Tested on the staging preview:
- [x] Run valid and invalid SQL from an Explorer query tab. Each run
emits one submitted event and one matching completed or failed event
with the same run ID.
- [x] Run database and Logs notebook query cells, then add a markdown
cell. The query cells emit matching event pairs; the markdown cell emits
no query event.
- [x] Save a new notebook, then edit and save it again. The successful
saves emit created and updated events.
- [x] Cancel a guarded query. It emits no query run event.
- [ ] Recreate a notebook deleted on the server after local edits. A
successful save emits created, not updated.
- [x] Inspect an Explorer action event request. Its page title is
`Explorer`; page visits still use the browser title.
- [ ] Force a notebook save failure. It should emit no save event. This
case was not tested manually.
## Linear
- fixes GROWTH-1298
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Analytics**
* Explorer query runs are tracked for database and log queries,
including whether they complete or fail.
* Query activity is associated with its location in Explorer, such as a
query tab or notebook cell.
* Successful notebook saves are tracked as creations or updates.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
Disables network bans for v3 (`AWS_K8S`) projects and shows a specific
unsupported notice. The shared banned-IP query waits for project details
and skips unsupported projects, covering both Database Settings and
Advisor for v3 and High Availability projects.
The hook returns the standard query result and uses `skipToken` to
prevent unsupported requests, including manual refetches. Database
Settings handles project-detail errors at the call site. Open unban
confirmations are cleared when the section becomes disabled, and
submission checks eligibility.
Addresses
[FE-4483](https://linear.app/supabase/issue/FE-4483/disable-network-bans-for-v3-aws-k8s-projects).
## To test
- Open Database Settings on a v3 project. Check that Network bans shows
the v3 notice, hides the IP list and unban controls, and makes no
network-bans retrieval request on initial load or reload, including
while Advisor is mounted.
- Check that an HA project still shows its existing notice and makes no
network-bans retrieval request on initial load or reload.
- Navigate from a supported project to a v3 or HA project and check that
no banned-IP request is sent for the unsupported project and no
banned-IP signals from the previous project appear in Advisor.
- If project details fail without cached data, check that Network bans
shows an error after retries finish and does not retrieve bans. A
successful retry should restore normal behavior.
- Open an unban confirmation on a supported project, then navigate to a
v3 or HA project. Check that the dialog closes without sending an unban
request and stays closed when returning. A newly opened confirmation
should still work.
- On a supported project, check the empty state and banned IP list.
Confirm that users with permission can unban an IP and users without
permission see a disabled button with the permissions tooltip.
Validation: 17 focused tests passed, covering automatic and manual
request suppression, project-detail error display and recovery, and
navigation between supported and unsupported projects. Changed-file
ESLint, Prettier, and full Studio typecheck (without the incremental
cache) passed. Earlier local browser checks on `9912c6c` confirmed no
retrieval requests for an HA project on AWS_K8S across reloads and
Advisor, and a successful empty state on a supported project. The local
failed-project case redirected to the organization after retries, so the
inline error remains verified by the component test only. The latest
preview, standalone v3 notice, populated bans/unban, and no-permission
tooltip still need browser verification.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Banned IP settings now show an unsupported-project notice for AWS
Kubernetes projects and hide ban lists and unban actions for AWS
Kubernetes and High Availability projects.
* Banned IP data loads only after project details are available and only
for supported projects; unsupported projects do not display cached ban
data.
* Project-detail errors are shown separately from ban-list errors.
* Unban confirmations close when a project becomes unsupported or an
unban succeeds. Unbanning is unavailable when you lack update permission
or the project is unsupported.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
## Summary
- Fixes MUL-1678: toggling High Availability on in the project-creation
wizard 400'd for orgs that are HA-entitled but not enrolled in the "V3
rollout ramp" feature flag on the backend, because two pre-flight
endpoints Studio calls before project creation didn't know about HA and
hit the ramp check the real create-project call already bypasses.
- Threads `highAvailability` through
`useOrganizationAvailableRegionsQuery` (`GET
/platform/projects/available-regions`, sent as
`high_availability=true|false` on the query string) and
`useProjectCreationPostgresVersionsQuery` /
`useAvailableOrioleImageVersion` (`POST
/platform/organizations/:slug/available-versions`, sent as
`high_availability` in the body), including their query-key cache keys
so HA and non-HA responses for the same org/provider/size don't collide.
- Wires the (already form-tracked) `highAvailability` value into every
call site: `ProjectCreationForm.tsx`, `RegionSelector.tsx`, and a new
`highAvailability` prop on `PostgresVersionSelector.tsx` passed from
`InternalOnlyConfiguration.tsx`.
## Problem
The project-creation wizard's HA toggle is wired into the actual
project-create request, but two pre-flight calls Studio makes before
that (available regions, available Postgres versions) had no way to
signal HA, so the backend's ramp-flag gate rejected them for HA-entitled
orgs outside the ramp.
## Solution
Add an optional `highAvailability` field end-to-end on the Studio side:
query hook variables, cache keys, request serialization, and the
components that already track the toggle via `useWatch`.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Available regions and database versions in project creation now
reflect the selected high-availability setting.
* The Create button remains disabled while available regions are
loading.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Signed-off-by: GuptaManan100 <guptamanan100@gmail.com>
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## Summary
* Adds the client query layer for `/api/status-page`
(`statusPageQueryOptions` in `data/platform/status-page-query.ts`) and a
shared normalization module (`lib/status-page/status-page.utils.ts`)
that maps the endpoint response into region- and project-creation-aware
`StatusItem`s — later PRs in this stack (assistant tool,
project-creation admonition, global banner) build on this same module.
* Wires the support form's status pill and incident admonition to the
new data behind the `incidentIoStatusPage` ConfigCat flag.
`useSupportStatus` branches between the new endpoint and the existing
`useIncidentStatusQuery`/`processIncidentData` path, both mapped to the
same `SupportStatus` shape.
* `IncidentAdmonition` becomes purely presentational; the status link
now points at the `pageUrl` returned by the endpoint instead of a
hardcoded URL.
Part of
[FE-4057](https://linear.app/supabase/issue/FE-4057/frontend-bannerbot-reconfigured)
— see Linear for full design context.
## Test plan
- [X] `pnpm --filter studio run typecheck`
- [X] `pnpm --filter studio run lint:ratchet`
- [X] `pnpm knip --workspace apps/studio`
- [X] `pnpm test:prettier`
- [X] `pnpm --filter studio exec vitest run` (touched files) — 70 tests
passing, including a flag-on case for `SupportFormPage`
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Support pages now display current incident and maintenance
information, including relevant status descriptions and links to the
status page.
* Status details can reflect items affecting a user’s region or
project-creation services. Upcoming maintenance is excluded from active
alerts.
* **Bug Fixes**
* Status labels and alerts now account for loading, errors, incidents,
and maintenance consistently across support pages.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
Follows up from [this
PR](https://github.com/supabase/supabase/pull/50799) - updates the Audit
Logs UI for organization audit logs. Just differs from Account audit
logs slightly with added "Actor" + "Target" column
Reuses the same UI components from account audit logs so quite a bit of
code clean up 🙂
<img width="1451" height="955" alt="image"
src="https://github.com/user-attachments/assets/a1002cee-917f-4d9a-b977-3fab8ecd2d13"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Organization audit logs now use a sortable table with row selection
and a resizable details panel.
* Actor details show a member’s username when available, otherwise the
actor’s email; a dash appears when neither is available.
* Logs can be filtered by users and projects, with separate messages for
no logs and no matching results.
* A refresh control and loading indicators help show audit-log updates.
* **Bug Fixes**
* Organization project lists stop loading when pagination totals are
unavailable.
<!-- 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?
If Realtime's admin_suspended_at is set we display a banner.
## What is the current behavior?
REAL-1095
## What is the new behavior?
<img width="1160" height="442" alt="Screenshot 2026-09-17 at 12 06
30 pm"
src="https://github.com/user-attachments/assets/f5abe900-a163-48c9-ab55-945fc62df0d1"
/>
## Additional context
Depends on https://github.com/supabase/platform/pull/38476
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Summary by CodeRabbit
- **New Features**
- Added a notice to Realtime settings when the service is suspended,
with instructions to contact support.
- **Bug Fixes**
- Improved invitation resending and role updates for roles without a
linked base role.
- **Tests**
- Added coverage to verify the suspension notice appears only when
applicable.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## Problem
The dashboard lists one row per foreign server, but deleting a row
dropped its foreign data wrapper with CASCADE. When multiple servers
shared a wrapper, deleting one removed all of them.
## Fix
Drop the selected server and its foreign tables. Remove the underlying
wrapper and Vault secret only when no servers still use it. Edits to a
shared wrapper now stop before making changes because the existing edit
flow recreates the underlying wrapper.
## How to test
1. Configure two BigQuery foreign servers that use the same foreign data
wrapper. Delete one from the dashboard.
2. Confirm the other server and its foreign tables still exist and work.
3. Delete the remaining server. Confirm the foreign data wrapper and its
Vault secret are removed.
4. Attempt to edit one of two servers sharing a wrapper. Confirm the
edit fails without removing either server.
Focused pg-meta tests and typecheck pass.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Shared connections are identified in the integrations list, with
guidance for editing them in the SQL Editor. Editing is disabled when a
wrapper is shared, with an explanation shown.
* Deleting a connection removes its foreign tables and removes the
wrapper and Vault secret only when no other connection uses them.
* **Bug Fixes**
* Connection deletion verifies that the selected server still belongs to
the wrapper and reports failures using connection-focused wording.
* Attempts to edit a wrapper used by another connection are blocked with
a clear explanation.
* Connection deletion and confirmation messages now consistently refer
to deleting a connection.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
Storage's `list` (v1) endpoint is being deprecated in favor of
`list-v2`, which uses cursor pagination instead of numeric offset (which
degrades on large buckets) and fixes folders that differ only by case
not both being listable. This is PR 1 of the migration (parent:
FE-4423); it covers the shared infinite-query hook and its two
consumers.
## Solution
Added `listBucketObjectsV2` alongside the existing v1
`listBucketObjects` (still used elsewhere, migrated in a later PR), and
replaced the `useBucketObjectsInfiniteQuery` hook with
`bucketObjectsInfiniteQueryOptions` built on `infiniteQueryOptions`,
following the repo's preferred data-fetching pattern. Pagination now
uses `hasNext`/`nextCursor` instead of an offset multiplier, and
`queryFn` rejects a response that claims `hasNext` without advancing the
cursor so a misbehaving backend can't send `fetchNextPage` into an
infinite loop. v2 splits results into separate `folders`/`objects`
arrays and has no `search` field, so the two consumers
(`BucketFilePickerColumn`, `MoveItemsFolderPicker`) merge/sort those
arrays themselves, and search is folded into a `prefix` match instead.
Also removed "Time last accessed" from the picker's sort dropdown since
v2's `sortBy.column` doesn't support it, with a defensive fallback to
`name` in case the shared sort preference (still used by the v1 main
file explorer) carries that value over. Added the missing self-hosted
`list-v2` API proxy route (`pages/api` + the TanStack `routes/api`
wrapper) using storage-js's `listV2()`, since self-hosted Studio only
had a v1 route and every v2 request was 404ing there.
## Review instructions
1. Open the bucket file picker (e.g. via an OAuth app logo upload),
confirm folders and files both render and paginate correctly, and that
searching still filters as expected.
2. Open the "Move items" modal's folder picker, confirm you can navigate
into and back out of subfolders, and that folder search still works.
3. Run `pnpm test:studio -- MoveItemsModal`.
## Checklist
- [x] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
- [ ] If I wrote a new docs topic or edited an existing topic, I used
the `/write-the-docs` or `/edit-the-docs` skill, which references
[WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md)
and the docs
[CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md)
guide
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Storage browsing loads large bucket listings in pages, helping keep
navigation responsive.
* Folder pickers display folders and files together across paginated
results.
* Moving items between folders uses the same paginated browsing
experience.
* Search remains available in the final folder level, and folder
navigation shows the correct contents.
* **Updates**
* “Time last accessed” is no longer available as a sorting option in
storage pickers. Sorting is available by name, creation time, or update
time.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
## Problem
The API Gateway report initializes its request range with the Logs
Explorer helper, which leaves `iso_timestamp_end` empty. When an OTEL
chart returns sparse microsecond timestamps, the time series filler can
interpret them as milliseconds while deriving the end of the range and
attempt an unbounded fill, freezing or crashing the browser tab.
## Fix
Initialize the report with its date range helper so both request bounds
are present. Normalize microsecond timestamps before deriving fill
bounds, including the single point case. Add regression tests for sparse
OTEL data with both empty and explicit end dates.
## How to test
- Open Observability → API Gateway on a project with requests spanning
two hourly buckets. The page should render without a tab crash, and the
analytics requests should include a nonempty `iso_timestamp_end`.
- Run `pnpm --filter studio exec vitest run
tests/features/logs/Logs.utils.test.ts` and confirm the microsecond
timestamp cases pass.
- Run the Studio typecheck and lint checks.
The Vitest, typecheck, and lint commands could not run in this worktree
because Studio dependencies are not installed. The source diff passed
`git diff --check` and received a focused code review.
## Problem
Studio copy ties disk IO burst behavior to compute size thresholds and
says the IO budget "resets".
Burst eligibility isn't a single size cutoff
EBS burst credits refill continuously while disk usage runs below
baseline
Docs already use this framing (#50016)
Fixes PROD-665
## Solution
Three copy changes:
- `UnavailableChartBlock.tsx`: the burst balance chart placeholder no
longer names a size. It now describes sustained IO with no burst credit
pool
- `database-charts.ts`: the Disk IO Burst Balance tooltip describes the
EBS burst credit pool without referencing instance size
- `ResourceExhaustionWarningBanner.constants.ts`: the warning and
critical banners say the budget refills whenever disk usage runs below
baseline, instead of "resets"
## Review instructions
1. Read the diff. Copy changes only.
2. Optional: on a project with burstable disk IO, open Reports >
Database and hover the Disk IO Burst Balance chart title to see the new
tooltip.
## Checklist
Check all before review:
- [x] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
- [x] If I wrote a new docs topic or edited an existing topic, I used
the `/write-the-docs` or `/edit-the-docs` skill, which references
[WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md)
and the docs
[CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md)
guide
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Documentation
* Updated disk I/O chart messaging to explain that some compute types
sustain disk throughput without a burst credit pool to track.
* Clarified that disk I/O burst budgets refill when demand is at or
below baseline, and that throughput remains at baseline until the budget
refills.
* Updated the burst-balance chart tooltip to describe how compute uses
the EBS burst credit pool.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
Studio expected aliased fields from the last-used API-key endpoint, but
the live endpoint returns OTEL attribute names. This kept legacy API-key
activity unavailable and prevented Studio from showing activity for new
JWT signing keys. Tracks FE-2462 and FE-4315.
## Fix
Normalize the endpoint response at the data boundary, keep the
`showApiKeysLastUsed` feature flag, and show activity from the past 24
hours for new JWT signing keys. Legacy HS256 signing keys remain blank
because the analytics response does not provide a stable signing-key
record ID for them. The request remains hosted-only, permission-gated,
and non-blocking, and the existing last-rotated column remains intact.
## How to test
- Make a request with a legacy anon or service-role API key, then open
Project Settings > API Keys and verify its last request appears.
- Make an Auth request signed by a new JWT signing key, then open JWT
Keys and verify the matching key shows a Last used timestamp.
- Verify a new key without activity shows No requests in the past 24
hours.
- Verify the legacy HS256 signing-key row leaves Last used blank.
- Expected result: legacy API keys and new JWT signing keys display
activity from the shared endpoint without changing self-hosted Studio.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a **Last used** column for JWT signing keys on supported
platforms.
* Displays usage timestamps, loading and error states, or when a key has
had no requests in the past 24 hours.
* Usage tracking now includes both API keys and JWT signing keys.
* **Bug Fixes**
* Improved handling of usage records for legacy and current keys.
* Usage details appear only on supported platforms and for users with
the required permissions.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
<!-- ccr-slack-attribution -->
_Requested by **Saxon Fletcher** · [Slack
thread](https://supabase.slack.com/archives/C051L8U2EJF/p1789995309253479?thread_ts=1789995309.253479&cid=C051L8U2EJF)_
Resolves AI-1246
## Problem
**Before:** The Assistant's `list_policies` tool fails in about 70% of
traces. It only "succeeds" when the org has AI opt-in disabled, because
then it returns the privacy stub and never makes a request. When opt-in
is enabled, it runs the pg-meta query server-side with no
`Authorization` header, so the request is unauthenticated and fails. The
Assistant then falls back to `execute_sql`.
**After:** `list_policies` sends the caller's `Authorization` header,
the same way `execute_sql` in `studio-tools.ts` already does, so it
returns the project's RLS policies.
## Solution
`getTools` already receives `authorization` but didn't pass it to
`getSchemaTools`. This PR passes it through. `list_policies` builds `{
Authorization }` from it, and `getDatabasePolicies` gets an optional
`headersInit` argument that it forwards to `executeSql`, the same
pattern `getDatabaseFunctions` uses. Existing client-side callers of
`getDatabasePolicies` don't change.
Files: `lib/ai/tools/index.ts`, `lib/ai/tools/schema-tools.ts`,
`data/database-policies/database-policies-query.ts`, plus tests in
`lib/ai/tools/schema-tools.test.ts` (new) and
`lib/ai/tools/index.test.ts`.
## Review instructions
1. Read `schema-tools.ts` and compare it with the `authHeaders` handling
in `studio-tools.ts` (`execute_sql`).
2. On the preview, use an org with AI opt-in set to at least "schema"
and ask the Assistant to list the RLS policies on `public`.
`list_policies` should return the policies without falling back to
`execute_sql`.
Local gates (all passed):
- `pnpm typecheck` in `apps/studio` (next typegen + `tsc --noEmit`)
- `npx eslint` on touched files: 0 errors. The 2 warnings are on lines
this PR doesn't change.
- `npx vitest run lib/ai/tools/schema-tools.test.ts
lib/ai/tools/index.test.ts lib/ai/tool-filter.test.ts`: 24/24 passed. I
also ran the new header test against the old `schema-tools.ts` and it
failed, as expected.
- `SORT_IMPORTS=false npx prettier --config prettier.config.mjs --check`
on touched files
Follow-up, not in this PR: `getRlsKnowledge` in `fallback-tools.ts`
(self-hosted path) also calls `getDatabasePolicies` without headers,
even though a `headers` object is already in scope there.
## AI disclosure
Claude Code (agent) wrote this PR from the Slack request. @SaxonF (Saxon
Fletcher) is the accountable human owner. A human needs to review it
before merge.
## Checklist
- [x] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
- [ ] If I wrote a new docs topic or edited an existing topic, I used
the `/write-the-docs` or `/edit-the-docs` skill (N/A, no docs changes)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_0171Mk7SiKYLDDoAQvbDYfeK
---
_Generated by [Claude
Code](https://claude.ai/code/session_0171Mk7SiKYLDDoAQvbDYfeK)_
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
## Problem
The API Gateway and Data API observability reports still send legacy
BigQuery SQL to the logs.all endpoint. The Data API shared-report hook
also hardcodes logs.all, so the otelReports flag cannot move that report
to ClickHouse.
## Fix
- Add the ClickHouse requests-by-country query needed by API Gateway.
- Select API Gateway SQL and endpoint atomically from otelReports.
- Route the Data API PostgREST report through the existing tested OTEL
API query builders and logs.all.otel.
- Wait for ConfigCat before the Data API sends a request, avoiding an
initial legacy request while the flag loads.
- Keep logs.all behavior when the flag is disabled and leave other
shared reports unchanged.
## How to test
1. Enable otelReports and open API Gateway, then confirm its report
requests use logs.all.otel.
2. Open Data API and confirm all report requests use logs.all.otel with
a request.path filter for /rest.
3. Change the date range, add a filter, and refresh each report.
4. Disable otelReports and confirm both reports use logs.all.
All OTEL query shapes were tested individually against logs.all.otel.
The focused query suite and lint pass locally.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- API reports can use OpenTelemetry data when enabled.
- Added country-level request reporting, excluding requests without
country information.
- Added OpenTelemetry-backed PostgREST reports and Storage cache
hit/miss metrics.
- **Improvements**
- Reports wait for required configuration before loading data.
- Refreshing reports consistently refetches active metrics.
- Improved error handling for analytics query failures.
- Improved report accuracy with numeric time buckets and more precise
attribute filtering.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Gildas Garcia