mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 18:05:11 +03:00
codex/fix-tanstack-e2e
7
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Sean Oliver
|
2c651ddabc | fix(experiment): make dataApiRevokeOnCreateDefault flag reads shape-agnostic (#46289) | ||
|
Sean Oliver
|
fdceb29260 |
fix(telemetry): exposure event captures dataApiDefaultPrivileges + drop race-fix hook (#46085)
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Bug fix. ## What is the current behavior? This PR addresses three issues with the implementation of the `dataApiRevokeOnCreateDefault` experiment ([GROWTH-858](https://linear.app/supabase/issue/GROWTH-858)) on the frontend side: 1. The `project_creation_default_privileges_exposed` event payload captures `dataApiEnabled`, which is the parent "Enable Data API" toggle. That value defaults to `true` for everyone in both arms, which doesn't help understand how people are interacting with the form. 2. The hook itself was gating on PostHog JS SDK values rather than our backend server values being sent from `/telemetry/feature-flags`. 3. The form on `/new/[slug]` captures `dataApiDefaultPrivileges` defaults once at mount via react-hook-form's `defaultValues`. If the flag is still loading when the page mounts, `useDataApiRevokeOnCreateDefaultEnabled()` returns `false` (coerced from undefined), and the form locks the field to the legacy default of `true`. The flag later resolving has no effect, and treatment users get the legacy default visually and in the exposure event. ## What is the new behavior? 1. Main-surface payload now sends `dataApiDefaultPrivileges` — the form field the experiment actually controls (`true` = legacy grants kept, `false` = revoked on create). Post-fix data will let us read out whether treatment users actually got the new default. 2. Hook is simplified: drop `orgCountReady`, drop the `onFeatureFlags` subscription, drop the `posthogClient` import. It now fires once when the flag resolves, period. Vercel surface is unchanged (still no `dataApiDefaultPrivileges` since there's no user-facing toggle there). Tests updated. 3. New useEffect in `/new/[slug]` watches the raw flag value and syncs `dataApiDefaultPrivileges` to the correct experiment-driven default when the flag resolves, gated on `getFieldState(...).isDirty` so we don't clobber intentional user input. ## Additional context Backend half of this fix is at supabase/platform#32933 (passes `org_count` and `signup_timestamp` in `personProperties` so the audience filter actually evaluates correctly). Both PRs are needed for the experiment to bucket at 5% and be measurable. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Changes** * Telemetry now records the selected default-privileges setting (dataApiDefaultPrivileges) in project-creation events; the previous dataApiEnabled field was removed. * Project-creation flows apply the experiment-driven default for that setting once the experiment resolves, but they do not overwrite user-edited choices. Vercel new-project flow syncs with the experiment until the user changes the checkbox. * **Tests** * Updated tests to validate tracking, deduplication, and sync/timing behaviors for dataApiDefaultPrivileges. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46085?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 --> |
||
|
Pamela Chia
|
0bed80b340 |
chore(telemetry): clean up frontend event catalog (#45964)
## Summary Resolves 13 findings (2 HIGH, 5 MEDIUM, 6 LOW) from the frontend telemetry audit: 1 action-string collision, 1 camelCase experiment name, 9 dead events removed, 4 missing org groups attached, 1 ambiguous property renamed, 1 raw-string property narrowed, plus consolidations and a structural tightening on TABLE_EVENT_ACTIONS. ## Changes ### HIGH - Rename `EventPageCtaClickedEvent.action` to `www_event_page_cta_clicked` so it no longer collides with the pricing CTA event (which had a different schema sharing the same action string) - Snake_case the header-upgrade experiment exposure name (`headerUpgradeCta_experiment_exposed` → `header_upgrade_cta_experiment_exposed`); PostHog flag key and `?source=` URL param unchanged ### MEDIUM - Remove 4 dead `ProjectCreation*Step*` events (referenced a v2 route that doesn't exist; 0 emissions) - Remove 4 dead experiment exposure events: `ProjectCreationRlsOptionExperimentExposed`, `HomeNewExperimentExposed`, `TableCreateGeneratePoliciesExperimentExposed`, `TableCreateGeneratePoliciesExperimentConverted` (0 emissions) - Attach org group to `dpa_request_button_clicked` (0% had `$group_0` per Hex) - Delete `RegisterStateOfStartups2025NewsletterClicked` (interface naming outlier, 0 emissions, page renamed to 2026) - Rename `AssistantSuggestionRunQueryClickedEvent.category` to `mutationType` with tightened literal union (`'functions' | 'rls-policies' | 'unknown'`) - Attach org group to `project_creation_default_privileges_exposed` on Vercel surface via explicit `groupOverrides` (auto-injection misses because `useSelectedOrganizationQuery` is undefined on that page) ### LOW - Consolidate `IndexAdvisorBannerEnableButtonClickedEvent` + `IndexAdvisorDialogEnableButtonClickedEvent` into one event with `origin: 'banner' | 'dialog'` - Rename `ImportDataFileDroppedEvent` → `ImportDataFileAddedEvent` so the interface name matches the action and the verb is on the approved list - Rename `LogDrainConfirmButtonSubmittedEvent` → `LogDrainRemovedEvent` and action to `log_drain_removed` (fires on delete-confirm modal, matches `CronJobRemovedEvent` pattern) - Add `type` property to `CronJobRemovedEvent` (parsed from the job's command), matching the create/update event shape - Tighten `TABLE_EVENT_ACTIONS` values with `satisfies` against the event union so renames in the union fail typecheck here too - Attach org group to `www_pricing_plan_cta_clicked` at 5 emission sites when an org is available in the page context - Narrow `unified_logs_row_clicked.logType` from raw `string` to the 5-literal `LOG_TYPES` union (zod already validates server values) ### Bundled refactor Migrated 5 emission sites from deprecated `useSendEventMutation` to `useTrack` while their containing files were being edited: `DPA.tsx`, `DisplayBlockRenderer.tsx`, `Grid.tsx` (2 events), `DeleteCronJob.tsx`. Full sweep of the remaining ~79 files is a separate follow-up. ## Testing Mostly just renaming of events ## Linear - fixes GROWTH-798 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Standardized telemetry to a unified tracking system for more consistent analytics. * Simplified experiment exposure reporting for upgrade prompts. * **New Features** * More granular tracking for CSV import, cron job deletions, log drain removals, DPA downloads/requests, and pricing CTAs. * Assistant now classifies mutation queries more precisely. * **Bug Fixes** * Improved default-privileges exposure logic on Vercel deployments (skips when org missing). <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45964) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Sean Oliver
|
4c77ab5fef |
feat(telemetry): mirror org_count to PostHog person property (#45946)
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Feature + two follow-on fixes — small, scoped to telemetry / experiment plumbing. ## What is the current behavior? PostHog feature flags evaluated in Studio only have access to the `gotrue_id` person property (set in `useTelemetryIdentify`) and the `organization`/`project` group associations from pageviews. Flags can't target users by org membership without a behavioral cohort, which refreshes on a ~hourly schedule and lags behind real-time signup state. This is blocking the rollout of the `dataApiRevokeOnCreateDefault` experiment ahead of the May 30 default-privileges breaking change — we need to target brand-new dashboard signups with no prior org membership, and there's no person property to filter on. ## What is the new behavior? Three changes, scoped tightly to make experiment targeting reliable for brand-new signups: ### 1. Mirror `org_count` to a PostHog person property (`apps/studio/lib/telemetry.tsx`) The Studio `Telemetry` component now mirrors the user's current org-list length to a PostHog person property `org_count` via `posthog.identify(user.id, { org_count })`. The effect: - Subscribes to `useOrganizationsQuery` (shares the same React Query cache as `useSelectedOrganizationQuery`, so no extra network requests). - Dedupes via a ref keyed on `{ userId, orgCount }` so we only call identify when the value actually changes — handles user-switch (logout/login as different user with same count) correctly. - Generic enough to be useful beyond this experiment — analytics segmentation by org membership, future flags that depend on multi-org behavior, etc. ### 2. Merge pre-init identify properties (`packages/common/posthog-client.ts`) The previous `pendingIdentification` slot was a single-write buffer — calling `posthogClient.identify()` before the PostHog SDK initialized would overwrite any prior queued identify. Latent until this PR added a second identify caller (`org_count`), which exposed the last-write-wins behavior on first-visitor-before-consent flows. Now merges properties across pre-init calls for the same user so both `{ gotrue_id }` and `{ org_count }` land on the person record when the SDK flushes. Caught during Codex review. ### 3. Gate the exposure event on `org_count` being present (`apps/studio/hooks/misc/useDataApiRevokeOnCreateDefault.ts`) `useTrackDefaultPrivilegesExposure` previously fired on the first non-undefined value of the `dataApiRevokeOnCreateDefault` flag. For brand-new signups, this races the `org_count` identify: the initial `/flags/` response (before targeting can match) returns the untargeted variant, the exposure locks it in via `hasTracked`, then our identify fires and a subsequent `/flags/` refresh updates the flag — but the exposure has already recorded the wrong variant. Fix: gate the exposure on `org_count` being present on the SDK person, subscribing via `onFeatureFlags` so we pick up the post-identify `/flags/` response. Adds `posthogClient.getPersonProperty` as the local-state reader. Without this, the experiment would have a ~5-15% noise floor on cohort assignment for new signups. ## Verification End-to-end verified locally against the staging PostHog project (34343): - Local Studio's PostHog SDK has `$stored_person_properties: { gotrue_id: <uuid>, org_count: 1 }` after sign-in. - Both `$set` events landed server-side within ~300ms of each other, and the staging person record now shows `org_count = 1.0` with `gotrue_id` preserved. - Targeting query `person.properties.org_count == 1` works end-to-end against staging. ## Additional context Ref: [GROWTH-853](https://linear.app/supabase/issue/GROWTH-853) Targeting plan for the flag once shipped: `person.org_count == 1` plus a behavioral filter on recent `sign_up` event, at 5% rollout. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Telemetry now records and syncs the user's organization count as an analytics person property and avoids redundant identifications when unchanged. * Analytics client now merges queued identification properties made before initialization and exposes a method to read stored person properties. * **Bug Fixes** * Tracking now waits for organization-count readiness before firing certain exposure events to prevent missing data. * **Tests** * Added/updated tests to cover person-property behavior and gating logic. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45946) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Inian
|
e61853c59c |
fix(studio): clarify default privileges toggle covers tables (#45458)
<!-- 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 --> |
||
|
Alaister YoungandAlaister Young
|
75e08577c1 |
chore(studio): remove tableEditorApiAccessToggle flag (#45081)
Cleans up the `tableEditorApiAccessToggle` PostHog flag now that the gated UI is shipping to everyone. Follow-up to #45034 — the new project-creation checkbox makes the management UI a prerequisite, so no reason to keep it behind a flag. **Removed:** - `useDataApiGrantTogglesEnabled` hook - Old schemas-only multi-selector branch in the Data API settings page (the rich per-table / per-function toggles + default-privileges switch become the only UI) - Flag gate around the `<ApiAccessToggle>` section in the table editor side panel - Flag gates around `updateTableApiAccess` calls in the save pipeline (create / duplicate / update) - `tableEditorApiAccessToggleEnabled` telemetry property + stale JSDoc / docs references **Changed:** - `createTableApiAccessHandlerParams` no longer takes an `enabled` param — it was always `true` after removal ## To test - Integrations → Data API settings page: exposed tables, exposed functions, default-privileges toggle all render and save correctly - Table editor: creating, duplicating, and editing a table all run the expected Data API privilege updates - Project creation flow still works end-to-end (unchanged, but the submit telemetry no longer includes `tableEditorApiAccessToggleEnabled`) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Improvements** * API access configuration is now always available in the table editor and PostgreSQL settings, removing previous conditional gating. * Simplified the "Automatically expose new tables and functions" interface by consolidating UI branches. * **Documentation** * Updated telemetry guidance and examples with current feature-flag references. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com> |
||
|
|
d1a7d64e63 |
[FE-3023] feat(studio): default privileges toggle at project creation (#45034)
<img width="783" height="414" alt="Screenshot 2026-04-20 at 3 02 37 PM" src="https://github.com/user-attachments/assets/a353c35a-3de5-4bfa-ab31-829c79c43165" /> Adds a "Default privileges for new entities" checkbox under "Enable Data API" in both the main create flow and the Vercel deploy-button flow. Default checked (current behaviour). When unchecked, runs `buildDefaultPrivilegesSql('revoke')` after the base init script so new entities in `public` aren't auto-granted to `anon` / `authenticated` / `service_role`. This PR decouples the two surfaces: - **`tableEditorApiAccessToggle`** — unchanged; still gates only the integrations → Data API settings UI. - **`dataApiRevokeOnCreateDefault`** (new) — controls only the default state of the new checkbox at project creation. `true` → checkbox unchecked by default (revoke runs); `false`/absent → checkbox checked by default (no behaviour change). The new flag is already live in PostHog at **0% rollout, off for everyone**, so shipping this PR changes nothing until the flag is explicitly flipped. ## Added - `apps/studio/hooks/misc/useDataApiRevokeOnCreateDefault.ts` — reads the new PostHog flag. Returns `false` in `IS_TEST_ENV` so existing E2E flows don't silently change default behaviour. - Checkbox UI in `SecurityOptions.tsx` (main flow) and `pages/integrations/vercel/[slug]/deploy-button/new-project.tsx` (Vercel flow), with copy matching the integrations → Data API settings page. - Tooltip + dimmed state for the main-flow checkbox when "Enable Data API" is unchecked (can't configure default privileges if Data API is off). - Telemetry: `dataApiDefaultPrivilegesGranted` (raw checkbox value) and `dataApiRevokeOnCreateDefaultEnabled` (raw flag, conditionally included using the existing raw-flag pattern so undefined flag state → omitted property, not `false`). - Vitest unit tests for the new hook. ## Changed - `pages/new/[slug].tsx`: removed the `false &&` rollback guard. Revoke SQL now runs only when `dataApi && !dataApiDefaultPrivileges`. Dropped the now-unused `useDataApiGrantTogglesEnabled` import. - `pages/integrations/vercel/[slug]/deploy-button/new-project.tsx`: this flow was **never rolled back** — it still ran revoke whenever `tableEditorApiAccessToggle` was on for a user. Now correctly gated on the new flag + checkbox state. - `packages/common/telemetry-constants.ts`: added the two new properties and corrected the `tableEditorApiAccessToggleEnabled` docstring (it no longer claims to control project-creation revoke behaviour). ## Kill switch Flipping `dataApiRevokeOnCreateDefault` to off in PostHog fully disables the revoke SQL for new projects without needing a redeploy — the checkbox just defaults to checked again. ## Follow-ups (not blockers) - joshenlim's review comments on PR 43704: (1) Auth Policies table row incorrectly showing "exposed via Data API" based on schema-level check instead of table-level at `apps/studio/components/interfaces/Auth/Policies/PolicyTableRow/index.tsx:64`; (2) Data API integrations page showing zero exposed tables even after exposing one. Both unrelated to this PR but will be more visible once the checkbox lands. - Once this flag fully rolls out, the old `tableEditorApiAccessToggle` docstring/comments elsewhere should stop claiming it controls project creation. ## To test - **Flag off (default state, simulates post-merge):** create a project with and without "Enable Data API" checked. The new "Default privileges for new entities" checkbox should default to **checked**. Submitting should produce an identical result to today — new tables in `public` are reachable via the Data API. - **Flag on (simulate rollout):** override the flag locally. The checkbox should default to **unchecked**. Creating a project with it unchecked should run the revoke SQL; create a new table in `public` afterwards and confirm it's not reachable via the Data API until grants are added. - **Enable Data API off:** the new checkbox should render disabled + dimmed with a tooltip reading "Enable the Data API to configure default privileges." The revoke SQL should not run in this case regardless of checkbox state. - **Vercel flow:** repeat at `/integrations/vercel/<slug>/deploy-button/new-project` — verify both checkbox states. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added an "Automatically expose new tables and functions" checkbox to project creation and Vercel deploy flow; enabled only when Data API is available (disabled with tooltip otherwise) and affects initial project provisioning. * **Telemetry** * Tracks exposure of the default-privileges control and includes checkbox state and feature-flag status on project-creation submissions. * **Tests** * Added tests for flag behavior, exposure tracking, deduplication, and submission telemetry. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com> Co-authored-by: Sean Oliver <882952+seanoliver@users.noreply.github.com> |
