Files
supabase/.github/instructions/studio-telemetry.instructions.md
T
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>
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