[bnjjj]

Adds supabase warehouse enable --schema <schema> [--table <table>] with hosted project selection, previewed table confirmation, and optional bounded synchronization waiting.

Uses the shared v2 setup API in explicit enable mode. Structured output distinguishes accepted setup from completed initial synchronization; completion checks table identities, replication state, and DNS readiness.

Depends on https://github.com/supabase/platform/pull/41439. Deploy the API before releasing this command and refresh the generated client from the deployed specification afterward.

How to review

1. Start in apps/cli/src/commands/warehouse/enable/ with SIDE_EFFECTS.md and enable.command.ts: check flags, hosted targeting, permissions, and the explanation that schema selection includes only existing eligible tables; future tables must be added separately.
2. Follow enable.handler.ts from preview through confirmation to setup. The selected tables and schema reminder appear before consent, and setup sends the confirmed table identities with mode: "enable".
3. Review polling and error handling: acceptance must not imply completion; waiting requires matching table identities, initial copies, a running pipeline, and ready DNS. Check terminal failures, bounded timeouts, actionable errors, and cache/telemetry finalizers.
4. Read enable.integration.test.ts and enable.e2e.test.ts for output, consent, waiting, and bookkeeping behavior. Review packages/api/src/generated/ last, focusing on the three Warehouse operations and their request/response contracts.

[github-actions]

CLI benchmark (Lightweight Commands): no changes found

Commit e6e25f0 against develop at 4cc97fa · 10 runs each · report only, never blocks merging

Command	Workload	Before	After	Change
supabase --version	version	152 ms	154 ms	no real change
supabase --help	help	155 ms	155 ms	no real change
supabase init	init	154 ms	158 ms	no real change
supabase migration new bench	migration-new	158 ms	158 ms	no real change
supabase gen types --lang typescript --project-id replayfixtureprojref	gen-types	180 ms	181 ms	no real change
supabase projects list	projects-list	167 ms	167 ms	no real change
supabase functions list --project-ref replayfixtureprojref	functions-list	170 ms	170 ms	no real change

API calls: unchanged for all 7 commands.

Binary size: 134.8 MB, up 48.0 KB from 134.7 MB.

Details: timing ranges, API calls per command, slowest phases

Timing ranges

Command	Workload	Before range	After range	Change	Verdict
supabase --version	version	149-153 ms	148-157 ms	+3 ms (+2%)	within noise
supabase --help	help	150-160 ms	150-170 ms	0 ms (0%)	within noise
supabase init	init	151-170 ms	153-171 ms	+4 ms (+3%)	within noise
supabase migration new bench	migration-new	156-164 ms	156-161 ms	+1 ms (+0%)	within noise
supabase gen types --lang typescript --project-id replayfixtureprojref	gen-types	178-187 ms	178-187 ms	+0 ms (+0%)	within noise
supabase projects list	projects-list	164-172 ms	163-173 ms	-1 ms (0%)	within noise
supabase functions list --project-ref replayfixtureprojref	functions-list	168-176 ms	169-178 ms	0 ms (0%)	within noise

API calls per command

Command	Workload	Before	After	Endpoint changes
supabase --version	version	0	0
supabase --help	help	0	0
supabase init	init	0	0
supabase migration new bench	migration-new	0	0
supabase gen types --lang typescript --project-id replayfixtureprojref	gen-types	2	2
supabase projects list	projects-list	1	1
supabase functions list --project-ref replayfixtureprojref	functions-list	2	2

Slowest phases

No command moved beyond noise, so there are no phase deltas.

Workflow run

Comment /bench to run the lightweight benchmark (this comment) again on the latest commit, or /bench full to also run the integration-heavy benchmark, which posts in its own comment.

[github-actions]

🤖 AI Review

Verified all nine findings from both reviews. Six are confirmed, one is refuted because the shared API client already retries transient failures, and two remain uncertain because the available contracts do not establish the required backend behavior. No findings overlap.

Findings

Severity	Location	Category	Sources	Claim
🟡 MINOR	apps/cli/src/commands/warehouse/enable/enable.command.ts:81	test-coverage	claude	Registering warehouse enable with consent default No makes the existing hosted-consent inline snapshot fail because it omits this command.
🟡 MINOR	apps/cli/src/commands/warehouse/enable/enable.handler.ts:152	correctness	claude	A nonempty partial status table list immediately fails --wait as a selection change, potentially rejecting healthy setup if table registration is incremental.
🟡 MINOR	apps/cli/src/commands/warehouse/enable/enable.handler.ts:145	error-handling	claude	The table-error failure path reports only the overall setup status, omitting the failing table and obscuring why waiting stopped.
🟡 MINOR	apps/cli/src/commands/warehouse/enable/enable.handler.ts:93	correctness	claude	An empty successful preview is passed through to consent and setup, and an accepted zero-table setup could satisfy the table-completion checks.
🟡 MINOR	apps/cli/src/commands/warehouse/enable/enable.errors.ts:9	test-maintenance	codex	The five new Warehouse error tags are absent from the committed telemetry snapshot, causing the error-tag stability test to fail.
🟡 MINOR	apps/cli/src/commands/warehouse/enable/enable.handler.ts:39	error-handling	codex	Selection-conflict recovery guidance directs users to warehouse replication add/remove commands that do not exist.
⚪ NIT	apps/cli/src/commands/warehouse/enable/enable.handler.ts:205	output-contract	claude	The structured success payload omits selected_tables with --wait and instead exposes decoded status attributes at the top level, giving consumers two different selection representations.
⚪ NIT	apps/cli/src/docs/docs-spec.tables.ts:213	consistency	claude	The required --schema flag is missing from the completion-required table, so warehouse enable does not offer it as the required completion candidate.

Refuted findings (kept for transparency, not posted as review comments)

• apps/cli/src/commands/warehouse/enable/enable.handler.ts:138 (error-handling): A single temporary network error, 429, or 503 immediately aborts --wait because polling has no retry handling.
  Refuted: Retries already exist below the handler. command-platform-api.layer.ts:62-70 constructs the shared API client with retry settings. packages/api/src/internal/client.ts:235 defaults to five retries; lines 242-256 classify GET transport failures, 429s, and 5xx responses as retryable; lines 341-366 apply backoff and Retry-After handling. Failures can surface after exhaustion or retry-policy limits, but ordinary single transient failures do not immediately abort waiting.

Stats

Claude findings: 7 · Codex findings: 2 · Confirmed: 6 · Refuted: 1 · Uncertain: 2

---

Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: auto · Workflow run

This review runs once per PR. A maintainer can request another with a /ai-review comment.