Repository navigation
fix(cli): classify errored provider purchase results as failures - #2204
Conversation
…nerCloud#1900) A provider can return PurchaseResult{Success: true, Error: non-nil}. purchaseAuditStatus, purchaseSingleRec and logPurchaseOutcome keyed only on result.Success, so such a result was audited as "success" and printed with a success marker. Add purchaseSucceeded (Success && Error == nil) and use it for the audit status and the diagnostics on both the recommendation and CSV purchase paths. The returned PurchaseResult is left unchanged. Add a newServiceClient seam so the regression test drives the real purchaseSingleRec path with a fake provider. Closes LeanerCloud#1900 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reached
This review includes 2 billable files and costs up to $0.50. Or wait 59 minutes for your next included review. View limit details
Comment |
Independent review verdict: CLEAN for #1900 scope, head
|
|
@coderabbitai full review |
|
Merge gate met at
|
Root cause
The CLI decided whether a purchase succeeded using only
PurchaseResult.Success.executePurchasekeeps the provider's result as-is when the separate Go error is nil, so a provider result of{Success: true, Error: non-nil}was audited assuccessand printed with✅, even though the provider had reported an error.Fix
purchaseSucceeded(result), which isSuccess && Error == nil.purchaseAuditStatus, which both paths share, and in the success/failure diagnostics inpurchaseSingleRec(the recommendation path) andlogPurchaseOutcome(the CSV path).PurchaseResultis not mutated, so provider data stays the same (per the issue).newServiceClientpackage-var seam (defaults tocreateServiceClient) so the test can drive the realpurchaseSingleRecpath with a fake provider. Nothing changes at runtime.Closes #1900
Verification
New test file
cmd/purchase_result_classification_test.gocovers four cases on bothpurchaseSingleRecandrunOnePurchase+logPurchaseOutcome: ordinary success,Success=truewith a provider error,Success=false, and a separate Go error. Each case checks the audit status and the ✅/❌ diagnostic.Fail-before: the seam was added, the fix was not yet applied, and the commands were run on macOS.
Pass-after, with the fix applied:
AWS_CONFIG_FILE=/dev/null AWS_SHARED_CREDENTIALS_FILE=/dev/nullis set only because the dev machine's~/.aws/configdefault profile is invalid, which breaks some existing tests. It is unrelated to this change.Coverage gap: this was verified only with a mocked provider (
MockServiceClient). No real purchase was made and the CLI was never run with--yes. None of the pinned cloud-commitments-go AWS providers is known to returnSuccess=truewith an error today, so this is a defensive fix.Out of scope (not changed here)
Other places still read only
result.Success. They would still treat such a result as successful:cmd/multi_service_stats.go(calculateServiceStatssuccessful/failed counts)cmd/interrupt.go(printInterruptedSummaryskips it from the "verify in AWS" list;auditStopMessagelabels it with a commitment ID)cmd/multi_service_csv.go(the CSVSuccesscolumn prints the raw flag)These could switch to
purchaseSucceededin a follow-up if maintainers want summaries to match the audit status.Maintainer: please mirror the issue's triage labels on this PR (the author lacks label permissions):
triaged,priority/p2,severity/medium,urgency/this-quarter,impact/few,effort/s,type/bug.🤖 Generated with Claude Code