docs(cli): disclose --high-availability as TS-only on projects create#5800
Conversation
… safe-list --high-availability has no Go CLI equivalent (Go's create.Run never sets HighAvailability even though the API field exists), but was undisclosed — unlike --reveal on projects api-keys, which explicitly documents itself as TS-only. It was also listed in safeFlags alongside org-id, implying Go parity that doesn't exist (Go marks only org-id telemetry-safe). Since it's a boolean flag, this has no runtime telemetry effect (boolean values are always logged verbatim regardless of safeFlags), but the array wrongly implied otherwise. Disclosed in SIDE_EFFECTS.md and a code comment, matching the --reveal precedent, and removed high-availability from safeFlags. Fixes CLI-1870.
Missed from the initial disclosure commit — the "Flag divergences from the Go reference" section already tracks --reveal for exactly this purpose (apps/cli/CLAUDE.md requires updating this doc when a command's flag surface changes).
The architect reviewer noted the previous citation (cmd/projects.go:133-143) pointed at the flag-registration block, which proves the flag doesn't exist, but the comment's claim about the request body was better evidenced by the RunE closure's body construction a few lines earlier. Cite both.
|
@codex review |
|
Codex Review: Didn't find any major issues. Nice work! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
…0-projects-create-remove-or-disclose-ts-only-high-availability # Conflicts: # apps/cli/src/legacy/commands/projects/create/create.command.ts
|
@codex review |
|
Codex Review: Didn't find any major issues. 🚀 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
…0-projects-create-remove-or-disclose-ts-only-high-availability # Conflicts: # apps/cli/docs/go-cli-porting-status.md
|
@codex review |
|
Codex Review: Didn't find any major issues. You're on a roll. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Supabase CLI previewnpx --yes https://pkg.pr.new/supabase/cli/supabase@d86f576c576e7679ab6d340eb223387f90c47386Preview package for commit |
Coly010
deleted the
columferry/cli-1870-projects-create-remove-or-disclose-ts-only-high-availability
branch
2 participants
What kind of change does this PR introduce?
Docs update (Go parity disclosure) + telemetry-list correctness fix.
What is the current behavior?
--high-availabilityonprojects createhas no Go CLI equivalent — Go'scmd/projects.gonever registers such a flag, and itsRunEclosure never setsHighAvailabilityon the create request body even though the underlying Management API field exists. Unlike--revealonprojects api-keys(which explicitly documents itself as a TS-only addition, in a code comment,SIDE_EFFECTS.md, anddocs/go-cli-porting-status.md's "Flag divergences" list),--high-availabilitywas undisclosed everywhere.It was also listed in
safeFlags: ["org-id", "high-availability"], implying Go-parity telemetry-safety that doesn't exist (Go'smarkFlagTelemetrySafeonly coversorg-id). Since it's a boolean flag, this had no actual runtime effect — boolean flag values are always logged verbatim by the instrumentation regardless ofsafeFlagsmembership — but the array wrongly implied otherwise.The linked ticket (CLI-1870) offered two valid resolutions: remove the flag for strict parity, or disclose it as TS-only. This PR disclosure, since
--high-availabilityis a real, working, user-facing capability that Go's CLI simply never got around to exposing (not a Go bug being ported forward) — removing it would regress anyone currently relying on it.What is the new behavior?
--high-availabilityis now disclosed as TS-only in a code comment,SIDE_EFFECTS.md, anddocs/go-cli-porting-status.md's "Flag divergences" list, matching the--revealprecedent exactly. Removed fromsafeFlags(now just["org-id"]) to match Go's actual telemetry-safe set.Fixes CLI-1870.