## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES/NO
## What kind of change does this PR introduce?
Bug fix, feature, docs update, ...
## What is the current behavior?
Please link any relevant issues here.
## What is the new behavior?
Feel free to include screenshots if it includes visual changes.
## Additional context
Add any other context or screenshots.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Accessibility**
* Improved screen-reader label for table row action menus so table
controls are clearer for assistive‑technology users.
* **Tests**
* Enhanced end-to-end test reliability: tightened selectors, added
dialog/toast visibility and API-wait synchronization, scoped lookup
fixes, removed redundant cleanup helper, and updated test setup to mark
a terms-of-service dismissal to reduce flakiness.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
This PR overrides title, description, content, logo, images, docs url,
and site url from marketplace db for wrappers. If marketplace doesn't
yet publish a wrapper listing, the page falls back to the hardcoded
content we show today.
It also improves the marketplace listings and categories queries by
returning typed results, making the code more type safe.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Studio integrations now surface updated marketplace metadata (name,
description, icon, docs, site, author, files) when available.
* Marketplace wrapper integrations are consolidated and shown alongside
studio integrations.
* **Refactor**
* Marketplace category and integration fetching rewritten for more
reliable loading, cancellation support, and improved menu/category
population.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46472?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?
Performance improvement / feature
## What is the current behavior?
The Schema Designer fetches all tables in a single request via
`useTablesQuery`. For schemas with 400+ tables this blocks first paint
on a large payload.
## What is the new behavior?
`SchemaGraph` uses `useInfiniteTablesQuery` (pageSize: 100) so the first
100 tables paint immediately. A "Load more tables" button appears above
the legend whenever more pages remain, letting users load the rest on
demand.
## Additional context
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a "Find table…" selector and keyboard shortcut to quickly locate
and focus tables; supports incremental loading and debounced name search
(with literal wildcard handling).
* Schema Graph shows a bottom "Load more tables" control with loading
state and preserves view after loading more.
* **Refactor**
* Table listing switched to infinite/paginated retrieval and improved
"no tables" logic; server-side name filtering supported.
* **Tests**
* E2E tests add a schema-visualizer wait helper and update flows to
support the paginated visualizer.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46402?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?
Update (third-party integration script).
## What is the current behavior?
The Default.com snippet on `/contact/sales` used the old `form_id`
(`299973`) and listened to the legacy HubSpot form element IDs
(`hsForm_de9a785a-…_5037`), which no longer match the form rendered on
the page.
## What is the new behavior?
The snippet now uses `form_id=879120` and listens to `["support-form"]`,
the actual `id` of the `RequestADemoForm` rendered on the page, so
submissions are enriched and routed correctly.
## Additional context
`team_id` and the loader logic are unchanged.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated form configuration on the sales contact page to enhance data
processing and routing.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46510?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?
Docs update.
## What is the current behavior?
The troubleshooting entry
`edge-functions-worker-timeouts-and-websocket-drops.mdx` includes
frontmatter fields that are not part of the troubleshooting
template/schema, so it does not conform to the expected metadata shape.
## What is the new behavior?
The document now matches the supported troubleshooting template
metadata.
- **Frontmatter cleanup**
- Removed unsupported `teams` and `types` fields.
- Kept the existing supported metadata (`title`, `topics`, `keywords`)
unchanged.
- **Template alignment**
- Brings the page in line with
`/apps/docs/content/troubleshooting/_template.mdx`.
- Avoids schema drift for troubleshooting content.
```mdx
---
title = "Edge Functions worker timeouts and WebSocket drops"
topics = [ "functions" ]
keywords = [ "websocket", "timeout", "earlydrop", "wall clock", "cpu limit", "streaming", "cold start" ]
---
```
## Additional context
This is a surgical docs-only change to make the page consistent with the
troubleshooting content schema used by the docs app.
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Rodrigo Mansueli <rodrigo@mansueli.com>
Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
Adding broad RLS policies to public buckets can cause users to expose
more than they expected, like the ability to list all profile pictures
on an app. This patches Assistant with knowledge to follow our latest
guidance on restrictive RLS policies for storage buckets
https://github.com/supabase/supabase/pull/46172
**Changes**
- Adds Storage bucket evals for public website assets and avatar access
patterns to distinguish public vs private bucket use cases
- Adds eval for overly permissive table policies
- Adds `storage` knowledge so Assistant distinguishes public buckets,
private buckets, object reads, and object listing.
- Adds `includeToolCallInputs` option for scorer transcripts so LLM
judges can evaluate proposed SQL/tool actions.
- Bumps max step count to 10 since storage knowledge may incur another
tool call (also 10 is recommended
[here](https://vercel.com/academy/ai-sdk/multi-step-and-generative-ui#why-multi-step-is-required)
for complex multi-tool scenarios)
**References**
-
https://supabase.com/docs/guides/storage/buckets/fundamentals#public-buckets
- https://supabase.com/docs/guides/storage/security/access-control
- https://github.com/supabase/supabase/pull/46172
**Notes:**
- These prompt tweaks are not meant to be exhaustive fixes, they are
mainly hotfixes intended to hold us out until these cases can be
addressed more deeply in skills/docs and tracked in a central evals
Closes AI-676
Closes AI-756
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added Storage knowledge resource for the assistant covering Supabase
Storage access patterns and RLS guidance.
* Added three evaluation cases: two for Storage (marketing assets,
avatars) and one for RLS policy generation for user profiles.
* **Improvements**
* Evaluators now include tool call inputs when judging conversations.
* Assistant prompts and generation enhanced with richer Storage/RLS
guidance and extended streaming limits.
* **Tests**
* Added test ensuring tool call inputs are included in serialized thread
context.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46168?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
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Simplified the local setup instructions for running the docs site
during development.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
The global `TooltipProvider` in `apps/studio/pages/_app.tsx` sets
`delayDuration={0}`, so every tooltip in Studio appears instantly on
hover. This makes tooltips easy to trigger accidentally while moving the
cursor, and contributed to issues like FE-3499 (status code tooltip in
Unified Logs).
The zero delay was introduced in #32679 when tooltips were migrated to
shadcn, without a stated reason.
## Fix
Remove the `delayDuration={0}` prop so tooltips use the Radix default
(700ms).
## How to test
- Open Studio
- Hover briefly over icons, buttons, and other elements with tooltips
- Expected: tooltips no longer appear instantly; they show after a short
hover delay
- Hovering long enough (around 700ms) still shows the tooltip as before
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Updated tooltip behavior to use default delay duration instead of
immediate display.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46456?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 — lints the analytics SQL wire boundary and tightens
internal API surface. Final PR in the safe-analytics-sql series (stacked
on #46476).
## What is the current behavior?
After PRs 1–10, every analytics SQL call site routes through
`executeAnalyticsSql`, but nothing prevents a future caller from
regressing by calling
`post('/platform/projects/{ref}/analytics/endpoints/logs.all', …)`
directly. `safe-analytics-sql.ts` also exports `rawSql` and
`LogSqlFragmentSeparator`, neither of which has external consumers —
`rawSql` in particular is a cast-to-brand escape hatch that should not
be reachable from outside the file. The safe-sql-execution skill
documents only the pg-meta (Postgres) side of the model.
## What is the new behavior?
- Adds an ESLint `no-restricted-syntax` rule in
`apps/studio/eslint.config.cjs` that fails on direct `post()` / `get()`
calls against
`/platform/projects/{ref}/analytics/endpoints/logs.all{,.otel}` outside
the `executeAnalyticsSql` wrapper.
- Un-exports `rawSql` and `LogSqlFragmentSeparator` from
`safe-analytics-sql.ts`; updates the `SafeLogSqlFragment` docstring
accordingly.
- Adds an "Analytics SQL" section to
`.claude/skills/safe-sql-execution/SKILL.md` covering the disjoint
`SafeLogSqlFragment` brand, the helpers, the wire boundary, and the new
lint.
## Additional context
Resolves FE-2949
## Summary
PR 10 of the analytics SQL safety series. Migrates the last surface of
analytics queries that flowed through plain
`get(.../analytics/endpoints/logs.all, { query: { sql } })` or the
`fetchLogs(projectRef, sql: string, ...)` helper over to
`executeAnalyticsSql` with branded `SafeLogSqlFragment` inputs.
After this PR, every analytics SQL call site builds its query through
the safe-analytics-sql helpers and hits the wire through the single
`executeAnalyticsSql` boundary. User-controlled values (filter
operators, numeric thresholds, function IDs, regions, provider names)
all flow through `analyticsLiteral` / branded operator maps; static
fragments are wrapped in `safeSql`. PR 11 (ESLint / vitest rule
forbidding direct analytics-endpoint POST/GET outside
`executeAnalyticsSql`) is the next and final step.
## Changes
- **`hooks/analytics/useProjectUsageStats.tsx`** — route the
already-branded `genChartQuery` output through `executeAnalyticsSql`
(parallels `useLogsPreview`).
- **`data/reports/report.utils.ts`** — tighten `fetchLogs(sql)` from
`string` to `SafeLogSqlFragment`; the wire boundary is now the same
single `executeAnalyticsSql` wrapper used by the rest of the analytics
path. Adds two pre-branded fragment maps reused by the report configs:
- `SAFE_GRANULARITY_SQL` — closed set returned by
`analyticsIntervalToGranularity`.
- `SAFE_COMPARISON_OPERATOR_SQL` — closed set on
`NumericFilter.operator`.
- **`components/interfaces/Auth/Overview/OverviewErrors.constants.ts`**
— wrap the two static `AUTH_TOP_*_SQL` fragments in `safeSql` (no
interpolation, but the type now flows).
- **`data/reports/v2/edge-functions.config.ts`** — `filterToWhereClause`
and every entry in `METRIC_SQL` now return `SafeLogSqlFragment`.
User-controlled values (`status_code.value`, `execution_time.value`,
function IDs, regions) pass through `analyticsLiteral`; operators look
up the branded map; the granularity uses the branded map. The
wire-format strings are unchanged, so the existing
`edge-functions.test.tsx` exact-string expectations still hold.
- **`data/reports/v2/auth.config.ts`** — same shape applied to all ten
`AUTH_REPORT_SQL` entries. The legacy `whereClause.replace(/^WHERE\s+/,
'')` pattern is replaced by two helpers that emit `AND`-prefixed
predicate fragments directly (`authFiltersToAndPredicates`,
`edgeLogsFiltersToAndPredicates`). Static provider SELECT / GROUP BY
fragments are pre-branded.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Enhanced security for analytics and reporting queries by updating
query construction methods across auth, edge functions, and project
usage reports.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46476?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?
- Minor issues here, the validation for creating names is there but
users can create crons with empty names through SQL
- When they edit the name in the Cron editor, since we use names as the
where clause it treats it as a new create
- So a duplicate cron is created
- Since creating requires a name, the validation is moved to the
component rather than zod and disabled when editing mode is on!
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Cron jobs can now be created without requiring a name field.
* Improved handling to properly distinguish between creating new cron
jobs and editing existing ones.
* **Bug Fixes**
* Fixed issue where editing unnamed cron jobs would create duplicate
entries instead of updating the existing job in place.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46486?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?
docs update
## What is the current behavior?
Storage RLS polices unintentionally allow list access to buckets
potentially setting a bad example for people starting a new project.
## What is the new behavior?
Use more restrictive RLS polices that only allow the intended operations
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Updated Supabase Storage access-control policies and examples across
docs and starter projects.
* Tightened avatar image access rules to require explicit operation
checks for public reads.
* Clarified guidance and added explanatory comments in migration and
README examples to illustrate the updated access patterns.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46172?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 -->
---------
Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
## 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?
Docs update
## What is the current behavior?
The dashboard branching guide doesn't mention that the first "Create
branch" action on a project requires Owner/Administrator access.
Combined with cosmetic UI behavior: the branch dropdown displays `main /
PRODUCTION` on every project from day one, even though the backend
hasn't registered a production branch yet. Developer-role users hit a
403 with a generic "Not authorized to enable preview branching" toast on
their first branch attempt, with no docs or UI hint that an implicit
production-branch registration step is happening.
Customer-reported in
[SU-383693](https://supabase.frontapp.com/open/cnv_1mz95u3i?key=wbyHQkruuZ_KYRGnRPB5_yHzm5-fr_k4)
## What is the new behavior?
Adds an admonition under the "Creating a branch" heading in the
dashboard-branching guide explaining:
- The cosmetic UI vs. backend state mismatch (`main / PRODUCTION` shown
before any row exists)
- That the first "Create branch" click is what technically enables
branching on the project (populates `preview_branches` with`is_default =
true`)
- This step requires Owner/Administrator access
- After that one-time step, anyone with the Developer role can create,
update, and delete preview branches
Scoped to the gitless dashboard flow only. The GitHub-integrated path
bootstraps automatically during admin-only integration setup.
## Additional context
- Mechanism confirmed with the team in
[Slack](https://supabase.slack.com/archives/C02BJ2239GA/p1779978863774239)
"the first time branching is used we populate the preview_branches table
with the base project and have is_default set as true. This is
technically what enables branching. A developer role can't do that."
- Related FE improvement being escalated separately (clearer error
message and/or disabling the Create branch button for Developers when
the production branch hasn't been registered yet)
- The [Branching 2.0
announcement](https://supabase.com/blog/branching-without-git-is-now-the-default)
(May 2026) made gitless branching the default for new projects, and more
customers can walk into the dashboard flow without ever touching GitHub
integration.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added clarification on dashboard branching behavior when GitHub
integration is not configured, including details on branch dropdown
display and initial setup requirements with permission levels.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46471?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 -->
Co-authored-by: Claude Opus 4.7 (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?
Docs update
## What is the current behavior?
Currently, we have a doc that was created to provide details about
platform audit logs (organization level)
## What is the new behavior?
This adds a detail about account audit logs, which provide the same
details as the platform audit log. The difference is account audit logs
only show logs for the specific user account.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Enhanced Platform Audit Logs guide to clarify that each account has
access to separate Account Audit logs for tracking individual user
activity.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46467?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 -->
## Summary
Removes the preemptive 301 redirects from `/docs/llms.txt` and
`/docs/llms-full.txt` to root, and switches the docs homepage
`rel=alternate` to an absolute URL. The `/docs/*` paths never had a
producer in `apps/docs` (no route handler, no static file at
`public/llms.txt` or `public/llms-full.txt`); the redirects were cruft
from before the root paths were canonical. Now `/docs/llms*` cleanly
404s and the only advertised path is the root canonical per llmstxt.org.
## Changes
- Delete `/docs/llms.txt` and `/docs/llms-full.txt` 301 entries from
`apps/www/lib/redirects.js`
- Switch `apps/docs/app/page.tsx` rel=alternate `text/markdown` from
relative `/llms-full.txt` to absolute
`https://supabase.com/llms-full.txt`, so `basePath: '/docs'` does not
reconstruct the now-dead `/docs/llms-full.txt` path
## Testing
Verify on Vercel preview:
- [ ] `curl -sI -L <preview>/docs/llms.txt` returns 404 (no producer,
redirect removed)
- [ ] `curl -sI -L <preview>/docs/llms-full.txt` returns 404
- [ ] `curl -sI -L <preview>/llms.txt` returns 200 with `content-type:
text/plain`
- [ ] `curl -sI -L <preview>/llms-full.txt` returns 200, ~9 MB body
- [ ] `curl -s <preview>/docs/ | grep 'rel="alternate".*llms-full'`
shows the absolute `https://supabase.com/llms-full.txt` href (no
`/docs/` prefix)
Caveat: the absolute alternate URL points at production from preview
deploys. Acceptable because Vercel previews are `noindex` by default and
the existing `canonical: BASE_PATH` already crosses environments via
basePath resolution.
## Linear
- fixes GROWTH-881
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated documentation URL references to use absolute Supabase-hosted
paths
* Reorganized legacy product documentation redirects to new
markdown-based routes
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46468?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?
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?
Adds details about error handling in the protocol and what users can
expect when handling them in client libs
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Expanded Realtime protocol "Error handling": describes four error
delivery paths, client lifecycle and recovery behaviors, and which
errors close or preserve channels.
* Clarifies join rejection parsing and retry/backoff guidance for join
error codes, plus special-case join reasons.
* Details channel-level system errors, Postgres subscription
degraded-state and ID-consistency rules, broadcast/presence error
shapes, in-band access_token refresh, and reconnection sequencing.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46292?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?
Right now material views and views don't have any options on the context
menu, they only have a copy name. This adds copy schema, export CSV,
export SQL and delete table to that list
Added E2E tests to cover the use cases
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Delete views and materialized views via confirmation dialogs with
optional cascade
* Copy SQL definitions for views and materialized views
* Export views and materialized views as CSV and SQL from the entity
menu
* Confirmation modals now show dependency warnings and cascade toggle
consistently
* **Tests**
* End-to-end tests covering copy, export, and delete flows for views and
materialized views in the table editor
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46383?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 (naming consistency cleanup).
## What is the current behavior?
`ReportQueryLogs` exposed its SQL builder under a `sql:` field while
`ReportQueryDb` used `safeSql:`. Both already returned branded fragments
(`SafeLogSqlFragment` / `SafeSqlFragment`), so should consolidate on
`safeSql`.
## What is the new behavior?
Renames `sql:` → `safeSql:` on `ReportQueryLogs` so the two report-query
shapes use the same field name. Updates every Logs preset under
`PRESET_CONFIG[API|STORAGE]`, every entry and call site in
`SharedAPIReport.constants.ts`, and `getLogsSql` in `Reports.utils.tsx`.
Part of the analytics SQL safety series; PRs 10 (remaining analytics
callers) and 11 (ESLint rules) still to follow.
## Additional context
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Enhanced query handling across API analytics reports (requests, top
routes, errors, performance metrics) and Storage analytics reports
(cache metrics) for improved consistency in query processing.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46469?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 -->
## What kind of change does this PR introduce?
Feature. Resolves FE-3470.
## What is the current behavior?
Organization surfaces have a `G then ,` shortcut to enter org settings,
but once inside there is no keyboard navigation, sidebar tooltips, or
action shortcuts for the various org pages.
| Area | Current behaviour |
| --- | --- |
| Org Settings sidebar | Routes are click-only once users are inside
Settings. |
| OAuth Apps | Publish / confirm actions have no keyboard shortcuts. |
| Private Apps | Create app has no keyboard shortcut. |
| Team | Invite / send actions have no keyboard shortcuts. |
| Integrations | Add project connection has no keyboard shortcut. |
| Org Projects | New project and search have no keyboard shortcuts. |
| Audit Logs | Refresh has no keyboard shortcut. |
## What is the new behavior?
Mirrors the Project Settings shortcut pattern (#46352) across all
Organization surfaces.
| Area | New shortcut coverage |
| --- | --- |
| Org Settings sidebar | `S then G/C/S/A/P/W/L/D` for General, Security,
SSO, OAuth apps, Private apps, Webhooks, Audit logs, Legal documents.
Shortcut badge appears on hover in the sidebar. |
| Org Settings entry | `G then ,` (remapped from `G then O`) to match
the Project Settings chord. |
| OAuth Apps | `Shift+N` opens Publish app panel; `Mod+Enter` confirms
the open panel. |
| Private Apps | `Shift+N` opens Create app sheet (works in both
empty-state and list-state). |
| Team | `Shift+N` opens Invite members dialog; `Mod+Enter` sends the
invitation(s). |
| Integrations | `Shift+N` triggers Add project connection when
permitted. |
| Org Projects | `Shift+N` navigates to new project; `Shift+F` focuses
the search input. |
| Audit Logs | `Shift+R` refreshes the log list. |
### Implementation notes
- Threads `shortcutId` through the `WithSidebar` pipeline (`SidebarLink`
→ `SubMenuSection` → `ProductMenuGroup`) so tooltip display is automatic
— no new rendering logic.
- Layout-scoped chords mount only while `OrganizationSettingsLayout` is
active, so `S then G` in org settings does not conflict with `S then G`
in project settings.
- Cheatsheet reference groups promoted to typed constants with readable
labels (was: bare strings like `'org-oauth-apps'`).
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* System-wide keyboard shortcuts for org areas: project search & new
project, private app creation, OAuth app publish/confirm, add GitHub
integration, invite members (open/submit), and refresh audit logs.
* Sidebar and product menu now show assigned shortcuts for faster
navigation; org settings navigation shortcut remapped.
* **Tests**
* Added coverage for org shortcut registry behavior, sequences, and
ordering.
* **Chores**
* New shortcut reference groups and ordering for improved
discoverability.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46356?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 -->
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Ali Waseem <waseema393@gmail.com>
Studio is on `react@^19.2.6`, and `useEffectEvent` shipped stable in
React 19.2 with the same signature as the userland polyfill. This drops
the local hook in `apps/studio` and `apps/www` in favor of the built-in.
**Removed:**
- `apps/studio/hooks/useStaticEffectEvent.ts`
- `apps/www/hooks/useStaticEffectEvent.ts`
- `.claude/skills/use-static-effect-event/` — skill is obsolete
**Changed:**
- 26 call sites: dropped the `useStaticEffectEvent` import, added
`useEffectEvent` to the existing `react` import, renamed call sites
- `.claude/CLAUDE.md`: `apps/studio` row updated React 18 → React 19
- `.claude/skills/vercel-composition-patterns/SKILL.md`: removed stale
"Studio uses React 18, skip these patterns" warning
## To test
- `pnpm typecheck --filter=studio` — passes locally
- `pnpm typecheck --filter=www` — passes locally
- `grep -rn "useStaticEffectEvent"` returns nothing outside
`node_modules`
- Smoke-test areas that use the hook: schema visualizer edges
(intersection check), spreadsheet import, sign-in/CLI login flows, side
panels with unsaved-changes prompts
**Out of scope:** pre-existing Tailwind lint warning on
`DefaultEdge.tsx:141` (`outline` + `outline-1` conflict) — unrelated to
this migration
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Internal event handling migrated to React’s built-in event hooks
across the Studio app; no user-facing changes.
* **Documentation**
* Clarified React 19 compatibility and noted Studio now targets React
19.
* Removed obsolete documentation for a deprecated internal hook.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46415?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 -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
## Context
Just removing unified logs related dead code (Not used, not imported)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Streamlined the Service Flow view by removing legacy timeline,
collapsible sections, and some detailed step UI for a cleaner
visualization.
* Simplified the Unified Logs surface by reducing exposed types,
consolidating query logic, and removing an internal event bus.
* Removed legacy list/detail and sheet UI pieces to tighten the logs
interface and public API surface.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46459?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 -->
## Context
Addresses DEBUG-126
Making some adjustments to the service flow panel in unified logs
- Row action will be via a `...` button instead of the whole row
<img width="487" height="207" alt="image"
src="https://github.com/user-attachments/assets/cd0f6d41-aace-41c2-872b-60071fd6b986"
/>
- Fields with no values will show a `-` (previously didn't show
anything)
<img width="501" height="130" alt="image"
src="https://github.com/user-attachments/assets/3b62c44e-7fd9-497b-8261-ca5e1c975bc2"
/>
- Opting to close the dropdown menu when scrolling to prevent overflow
of the dropdown menu content with the parent component
- However, IMO this needs to be addressed at the UI component level RE
how we want to handle dropdown menu content when scrolling. The content
is portalled hence why its happening
- (Not user facing) Clean up usage of `FieldValue` and
`DataTableSheetRowAction`
- Was confusing to be passing `value` as a react node when declaring
`DetailRow` from `PostgresFlowDetail` and `Block`
- Opting to render the UI inside `DetailRow` instead, which gives us
better control on the UI
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Dropdown menus now close when the page is scrolled while open.
* **Improvements**
* Cleaner, more consistent log value formatting and status code display.
* Loading placeholders for log fields are handled more consistently.
* Dropdown content area widened for better visibility.
* Row actions only appear when a value is present; copy action shown as
fallback.
* **UI Behavior**
* Collapsible section headers receive improved layout, transition, and
hover styling.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46462?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 / security hardening — continues the analytics SQL
provenance-tracking series (PR 8).
## What is the current behavior?
- `generateRegexpWhere` (unsafe: interpolates user-controlled filter
keys/values without escaping) still exists alongside
`generateRegexpWhereSafe` and its tests only cover the old function.
- `usePostgrestOverviewMetrics` builds a SQL query string with plain
string interpolation and calls the analytics endpoint directly via
`get()`.
- `edge-functions-last-hour-stats-query` builds a SQL query with
`functionIds` escaped via Postgres-only `quoteLiteral` and calls the
analytics endpoint directly via `post()`.
- `executeAnalyticsSql` has no way to pass a `key` query-string param
for network-tool identification.
- `rawSql('minute')` / `rawSql('hour')` / `rawSql('day')` and
`rawSql(value ? 'true' : 'false')` are used for static strings that
could be expressed with the `safeSql` template tag.
## What is the new behavior?
- `generateRegexpWhere` is deleted; its tests are replaced with
`generateRegexpWhereSafe` coverage including injection-attempt cases
(`level OR id IS NOT NULL`, `request.method); DROP TABLE edge_logs; --`)
that verify predicates are silently dropped rather than emitted.
- `usePostgrestOverviewMetrics` returns `SafeLogSqlFragment` from its
SQL builder and routes through `executeAnalyticsSql`.
- `edge-functions-last-hour-stats-query` uses `analyticsLiteral`
(BigQuery/ClickHouse-correct escaping) instead of `quoteLiteral`
(Postgres-only) and routes through `executeAnalyticsSql`.
- `executeAnalyticsSql` accepts an optional `key?: string` forwarded as
a query-string param on both GET and POST requests; `key:
'last-hour-stats'` is restored on the edge-functions query.
- Static `rawSql('...')` calls replaced with `safeSql\`...\`` template
literals throughout.
## Additional context
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Bug Fixes
- Removed legacy unsafe SQL-filter utility from Reports
## Chores
- Enhanced analytics SQL execution infrastructure with improved error
handling
- Added optional request identification parameter to analytics query
execution
- Refined SQL filtering mechanisms in reporting features
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46466?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 -->
## Context
Original task was to support searching `!=` on `event_message`, but this
PR addresses some things regarding searching on `event_message` in
unified logs that I found while working on this.
### `=` and `!=` are technically inaccurate
We're doing pattern matching when searching on event_message rather than
a strict equality check, so a more accurate operator would be `ilike
(~~*)` and `not ilike(!~~*)` - both of which would be case insensitive
for easier checking.
Am thus swapping to use these 2 operators when filtering on
`event_message`:
<img width="430" height="134" alt="image"
src="https://github.com/user-attachments/assets/c8a320b6-e016-44ae-aed0-1e7b6cefbda9"
/>
### Filtering on `event_message` was never server side
It seems like we have been only doing client side searching on
`event_message` which is inaccurate as we're only filtering against rows
that are on the current page. The `event_message` filtering was never
appended to the URL state as well so the changes in this PR ensures that
all search including `event_message` is server side.
### Rework on unified logs filtering via URL params
Because we're now supporting more than just `=` in unified logs, the
current filter system is insufficient (e.g can't just be
`status=x&method=y`). Am opting to use the same system as per how we do
filtering in the table editor where search params follow the syntax:
`{column}:{operator}:{value}`
<img width="521" height="46" alt="image"
src="https://github.com/user-attachments/assets/54e72eb2-1581-4c1a-910e-58d993da1766"
/>
## To test
- [ ] Verify that searching for logs in unified logs still works
- [ ] Verify that searching against event_message in unified logs works
as expected (both ilike and not ilike)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Repeatable URL-based column filters with operator support (e.g.,
equals, not-equals, pattern matching).
* Expanded pattern-style operators for message searches
(case-insensitive/contains, negation).
* **Improvements**
* Unified filter handling across logs list, charts, and counts for
consistent results.
* Range/slider filters and pagination remain supported and round-trip
via URL parameters.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46457?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
The Swap usage chart in the database report (Observability > Database)
displays inaccurate data.
## Fix
Set the swap-usage chart's `hide` flag to `true` in
[`database-charts.ts`](apps/studio/data/reports/database-charts.ts) so
it no longer renders. The chart definition is kept so it can be
re-enabled once the underlying metric is reliable.
## Test plan
- [ ] Open Observability > Database report and confirm the Swap usage
chart is no longer shown
- [ ] Confirm other charts (Memory, CPU, Disk, etc.) continue to render
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Corrected the visibility of the swap usage chart in reports—it is now
properly hidden from display.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46465?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 -->
Co-authored-by: Claude Opus 4.7 <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?
Right now our tests for API mocking is using vi.mock and mocking that
query or fetch handler. This is not the right approach IMO, 2 years ago
@jordienr added MSW with some very powerful helpers. The idea is to move
component test that rely on API using MSW within ViteTest. Principles
are simple:
- Mock API responses
- Mount your component that uses API responses
- Tests and assert on UI
- Added Skill for Clanker
This pattern is 100 times better than what we have
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Tests**
* Expanded and strengthened test suites for secrets, org lookup, support
flows, OAuth auth, and onboarding; mocks now use contract-backed
responses for more realistic coverage.
* **Documentation**
* Added a comprehensive guide describing a standardized pattern for
component tests that mock network requests.
* **Chores**
* Improved test helpers, typing for API mocks, and test runner
configuration for more reliable and maintainable tests.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46439?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 -->
---------
Co-authored-by: Alaister Young <alaister@users.noreply.github.com>
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
## Problem
In the unified logs UI, the status badge for a Postgres row showed a
different color in the detail view than in the table view. The table
view colors by the row's pre-computed `level` (derived in SQL from
`severity_text`), so a Postgres ERROR row's SQL state code (e.g.
`42P01`) renders red. The detail view re-derived the level via
`getStatusLevel(value)` which only handles HTTP numeric codes.
`Number('42P01')` is `NaN`, every branch fell through, and the badge
always rendered neutral regardless of severity.
## Fix
Color the status badge in the detail view by `data.level`, the same
canonical row level the table view uses. Threaded `level` through
`FieldValue` and used `data.level` directly in `BlockField`.
`getStatusLevel` is still used by the Webhooks platform views, where
`responseCode` is always a numeric HTTP status, so those callers stay
correct.
## How to test
- Open the dashboard and navigate to a project's unified logs page.
- Filter to `log_type: postgres` and find an ERROR row.
- Confirm the status code (a SQL state like `42P01`) is colored red in
the table.
- Click the row to open the detail pane and confirm the Status field in
the Postgres block is also red.
- Repeat with a WARNING-severity Postgres row, confirming both views
render warning color.
- Sanity check a 5xx HTTP row (PostgREST or Storage) still shows red in
both views, and a 2xx row stays neutral in both.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Improved consistency in how log level context is propagated through
logging interface components, enabling more uniform formatting and
rendering behavior across the unified logs display.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46450?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 -->
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Follow-up to #46413, which fixed an unwanted top border on the Auth
Users grid by upgrading `border-t-0` → `border-t-0!` so the Tailwind
rule actually wins over react-data-grid's `.rdg { border: 1px solid
var(--rdg-border-color); }` shorthand. The same issue exists on every
other DataGrid in Studio — this applies the fix consistently.
**Changed:**
- `border-t-0! border-b-0!` applied to all `<DataGrid>` call sites in
Studio (11 in total)
Fixes this issue everywhere:
<img width="609" height="223" alt="Screenshot 2026-05-28 at 3 40 02 PM"
src="https://github.com/user-attachments/assets/f49d8849-dd58-4675-ade4-a2656aadb8f9"
/>
## To test
Spot-check that the top/bottom borders look right (no doubled border
under the page chrome, no extra line at the bottom of the table) on each
route below. Use any project ref for `[ref]`:
- `/project/[ref]/observability/query-performance` — main grid + the
WithStatements grid inside
- `/project/[ref]/observability/query-insights` — both modes (explorer +
triage)
- `/project/[ref]/advisors/security`
- `/project/[ref]/advisors/performance`
- `/project/[ref]/integrations/cron/jobs` — jobs list
- `/project/[ref]/integrations/cron/jobs/<jobName>` — previous runs tab
- `/project/[ref]/integrations/queues/queues` — queues list
- `/project/[ref]/integrations/queues/queues/<queueName>` — single queue
messages
- `/project/[ref]/integrations/vault/secrets`
- `/project/[ref]/sql/new` — results pane at the bottom
- `/project/[ref]/realtime/inspector`
- `/project/[ref]/logs/explorer` — and the preview pages: `auth-logs`,
`edge-logs`, `postgres-logs`, `cron-logs`, `pg-upgrade-logs`,
`postgrest-logs`, `realtime-logs`, `replication-logs`, `pgcron-logs`,
`storage-logs`, `edge-functions-logs`, `pooler-logs`,
`dedicated-pooler-logs`
- `/project/[ref]/functions/[functionSlug]/logs` and `/invocations`
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Style**
* Refined border styling on data grids across multiple features
including integrations, query tools, and logs for improved visual
consistency.
<!-- review_stack_entry_start -->
[](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46448?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 -->
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Copy/export of selected rows in the Table Editor refetches full values
for cells truncated in the grid (via `getCellValue`), but that refetch
was bypassing role impersonation. The main grid query respects the
impersonated role; the truncated-cell hydration didn't, so the copy
could fetch as the service role even when "View as <role>" was active –
an inconsistency, since the UI still indicates the impersonated role is
in effect.
Threads `roleImpersonationState` through `hydrateTruncatedRows` →
`getCellValue`, and wraps the SQL in `wrapWithRoleImpersonation`
(matching how `getTableRows` does it). Addresses FE-3493.
**Changed:**
- `getCellValue` accepts an optional `roleImpersonationState` and wraps
its SQL with `wrapWithRoleImpersonation` + flags
`isRoleImpersonationEnabled` on `executeSql`
- `hydrateTruncatedRows` threads `roleImpersonationState` through to
`getCellValue`
- `Header.tsx`'s `onCopyRows` passes the in-scope
`roleImpersonationState` into `hydrateTruncatedRows`
## To test
1. Open the Table Editor on a table with a row containing a
large/truncated string value and a primary key
2. Enable role impersonation → "View as role" → pick any role with read
access to the table
3. Select the row, then `Copy → Copy as JSON` (also try CSV / SQL)
4. The copy should succeed and contain the full (non-truncated) value
5. Inspect the SQL request – it should now be wrapped with the
impersonation context, matching how the main grid query is wrapped
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
