Files
supabase/.github/instructions/studio-telemetry.instructions.md
Alaister 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>
2026-04-22 21:37:48 +08:00

3.3 KiB

applyTo
applyTo
apps/studio/**,packages/common/telemetry*

Studio Telemetry Review Rules

All comments are advisory — suggest, do not request changes.

When to Flag Missing Telemetry

Use judgment — not every PR needs telemetry. But always flag when:

  1. Changes to packages/common/telemetry-constants.ts — validate event naming, property conventions, and JSDoc accuracy.
  2. PostHog feature flags without measurement. If a PR uses usePHFlag or PostHog-backed hooks like useDataApiRevokeOnCreateDefaultEnabled to gate behavior, the flag state should be captured in a telemetry event so the rollout can be measured. Flag if the flag value isn't included in a relevant track() call. (Note: useFlag from common reads ConfigCat flags, not PostHog — different system, different guidance.)
  3. Feature-flagged rollouts without outcome tracking. If a flag gates new behavior, there should be telemetry on both the flag state and how users respond to the new behavior (e.g., toggle clicks, opt-in actions).
  4. Growth-oriented components adding user interactions without tracking — onboarding flows, setup wizards, upgrade CTAs, A/B experiment variants.

When tracking is missing, comment: "This adds a user interaction (or feature flag) that may benefit from tracking." Then propose an event name and useTrack() call.

Feature Flag Telemetry Pattern

When capturing a PostHog flag value for telemetry, read the raw flag via usePHFlag('flagName')not through wrapper hooks that coerce undefined to false. Use conditional spread so the property is omitted (not false) when the flag store hasn't loaded:

const flagValue = usePHFlag<boolean>('myBooleanFlag') // for boolean flags
track('event_name', {
  ...(flagValue !== undefined && { myFlagEnabled: flagValue }),
})

For string-valued flags (e.g., experiment variants), use usePHFlag<string>('flagName') instead.

Event Naming

Format: [object]_[verb] in snake_case.

Prefer verbs already in use in packages/common/telemetry-constants.ts: opened, clicked, submitted, created, removed, updated, intended, evaluated, added, enabled, disabled, copied, exposed, failed, converted, closed, completed, applied, sent, moved.

Flag: unapproved verbs (saved, viewed, pressed), wrong order (click_product_card), wrong casing (productCardClicked), passive view tracking on page load (exception: _exposed events for A/B experiments).

Event Properties

  • camelCase for new events; match existing convention when extending
  • Self-explanatory names — flag generic (label, value, name, data)
  • Check telemetry-constants.ts for consistency with similar events
  • Never track PII

Event Implementation

  • Use useTrack from lib/telemetry/track — avoid introducing new useSendEventMutation usage
  • New events need a TypeScript interface in telemetry-constants.ts with @group Events and @source JSDoc tags (add @page when applicable for page-specific events), added to the TelemetryEvent union
import { useTrack } from 'lib/telemetry/track'

const track = useTrack()
track('product_card_clicked', { productType: 'database', planTier: 'pro' })

Canonical standards: .claude/skills/telemetry-standards/SKILL.md