refactor(cli): clarify ProviderOptionsConfig and replace --reconfigure with --reset#471
Merged
Conversation
✅ Deploy Preview for devsydev canceled.
|
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
skevetter
force-pushed
the
address-pr469-comments
branch
2 times, most recently
from
May 31, 2026 16:45
fd34d79 to
cba4d8a
Compare
skevetter
changed the title
skevetter
force-pushed
the
address-pr469-comments
branch
from
May 31, 2026 16:48
cba4d8a to
f501fd9
Compare
skevetter
changed the title
skevetter
force-pushed
the
address-pr469-comments
branch
from
May 31, 2026 16:51
f501fd9 to
9d89a1b
Compare
skevetter
changed the title
skevetter
force-pushed
the
address-pr469-comments
branch
from
May 31, 2026 16:55
9d89a1b to
c30f82b
Compare
skevetter
changed the title
…orValues The 'Reconfigure' flag on ProviderOptionsConfig was opaque: it sounded like "should we run init again?" (which is what SkipInit controls) but actually toggled whether mergeExistingOptions seeds the new prompts with the user's previous answers. CodeRabbit reading PR #469 reached for 'Reconfigure: true' on 'provider set-source' defensively, assuming it prevented stale data leaking through the merge — but the downstream resolver already prunes stale keys and re-resolves invalid values regardless of this flag. Renaming the internal field to DiscardPriorValues makes the mechanism self-documenting at every call site: - cmd/provider/add.go: DiscardPriorValues=true (fresh install; no prior values to merge anyway, kept explicit for clarity) - cmd/provider/set_source.go: omitted (zero value); preserves prior values, resolver handles stale-key pruning - cmd/provider/init.go: bound to user-facing --reconfigure flag - cmd/provider/set.go: same - cmd/pro/update_provider.go: DiscardPriorValues=true (automated version bump, re-resolves from new schema defaults) - cmd/pro/login.go: omitted (zero value) User-facing --reconfigure flags on 'provider init' and 'provider set' keep their names; the rename is internal only. Also drops the redundant log.Errorf on set-source failure (the wrapped error already conveys the failure). Originally proposed adding Reconfigure: true to set-source per CodeRabbit feedback on #469; investigation showed that the resolver (pkg/options/resolver/resolver.go:153-157 and resolve.go:207-215) already prunes keys absent from the new schema and re-resolves values that fail validation, so the original Reconfigure: false on 'provider update' was correct and the rename preserves that behavior with clearer code.
skevetter
force-pushed
the
address-pr469-comments
branch
from
May 31, 2026 16:57
c30f82b to
17388b7
Compare
skevetter
changed the title
skevetter
enabled auto-merge (squash)
May 31, 2026 17:22
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.
Summary
Internal cleanup on the provider option-resolution surface plus a CLI rename to make the user-facing flag honest about its behavior.
Changes
Reconfigure→DiscardPriorValuesonProviderOptionsConfig. The old name sounded like "should we run init again?" (whichSkipInitalready controls); the flag actually toggles whethermergeExistingOptionsseeds prompts with the user's previous answers.Context→ContextNameonProviderOptionsConfig. Thestringfield colliding withcontext.ContextinConfigureProvider(ctx context.Context, cfg ProviderOptionsConfig)was a readability hazard.--reconfigurewith--resetonprovider init. Same capability ("discard previously stored option answers and re-prompt"), name now describes what it does. The flag is gone fromprovider set— that command is for targeted-o KEY=VALUEedits and the "set this key AND re-prompt for everything else" combined behavior had no real use case.log.Errorfonset-sourcefailure — the wrappedfmt.Errorf("configure provider: %w", err)already conveys it.Why
CodeRabbit on #469 suggested
Reconfigure: trueonprovider set-sourceto prevent "stale data" leaking throughmergeExistingOptions. Investigation showed the downstream resolver already prunes stale keys (pkg/options/resolver/resolver.go:153-157) and re-resolves values that fail validation (resolve.go:207-215). Forcing reconfigure would have re-prompted users for options whose values were still valid — UX regression, not a fix.A code-review bot reaching for the wrong tool is strong evidence humans would too. The renames and the flag rename address the root cause: every name in the struct and on the CLI should describe what it does.
Call site audit (6 sites, all updated)
DiscardPriorValuesprovider addtrue(explicit)provider set-sourceprovider initcmd.Reset--resetflagprovider setpro update-providertruepro loginFollow-up (separate PR)
Tests for
ConfigureProvider's merge semantics — currently zero coverage. Three scenarios to lock down: (a) preserves user-provided values whose keys remain in the new schema, (b)DiscardPriorValues=truediscards them, (c) keys absent from the new schema are pruned by the resolver regardless of this flag.