docs(cli): disclose --high-availability as TS-only on projects create#5800
Draft
Coly010 wants to merge 3 commits into
Draft
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.
Contributor
Author
|
@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". |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.