Problem. convertGCPRecommendation (all four GCP services) sets only EstimatedSavings and leaves Count, SavingsPercentage, CommitmentCost, OnDemandCost, BreakEvenMonths at zero.
- C1:
buildInsertRequest (computeengine/client.go:507-540) does Amount: int64(rec.Count) (and *4096 for memory) → a Recommender-driven purchase requests a 0 vCPU / 0 MB commitment. Green tests hide it (they hand-build Recommendation{Count:N}).
- C2:
pkg/scorer filters on SavingsPercentage (MinSavingsPct), BreakEvenMonths, Count (MinCount) — all zero for GCP → any non-zero filter silently drops all GCP recs; when they pass they rank to the bottom.
Evidence. computeengine/client.go:795-811 (converter), :507-540 (insert); pkg/scorer/scorer.go:80-90. GCP pricing fns compute the numbers but are only called from GetOfferingDetails, never the converter.
Impact. GCP CUD purchase happy-path is broken/useless; GCP recs silently filtered/mis-ranked. Money path.
Suggested fix. Extract vCPU count from the Recommender payload → set rec.Count; thread the pricing path into the converter to fill CommitmentCost/OnDemandCost/SavingsPercentage/BreakEvenMonths. Guard buildInsertRequest/PurchaseCommitment to refuse rec.Count <= 0. Also fix 10-M5 (per-service hardcoded PaymentOption — see #718/#829 for the monthly-stamp part). Regression test: realistic Recommender response → converter → Count > 0 and VCPU Amount set; through scorer with MinSavingsPct set, GCP recs survive.
References. Source: report 10 (C1, C2, M5) + architecture note on scorer contract. Related #264/PR #811 (RecurringMonthlyCost only), #718/PR #829 (payment-option monthly stamp).
Filed from automated adversarial code review (see docs/code-review/). Source finding(s): 10-C1, 10-C2, 10-M5.
Problem.
convertGCPRecommendation(all four GCP services) sets onlyEstimatedSavingsand leavesCount,SavingsPercentage,CommitmentCost,OnDemandCost,BreakEvenMonthsat zero.buildInsertRequest(computeengine/client.go:507-540) doesAmount: int64(rec.Count)(and*4096for memory) → a Recommender-driven purchase requests a 0 vCPU / 0 MB commitment. Green tests hide it (they hand-buildRecommendation{Count:N}).pkg/scorerfilters onSavingsPercentage(MinSavingsPct),BreakEvenMonths,Count(MinCount) — all zero for GCP → any non-zero filter silently drops all GCP recs; when they pass they rank to the bottom.Evidence.
computeengine/client.go:795-811(converter),:507-540(insert);pkg/scorer/scorer.go:80-90. GCP pricing fns compute the numbers but are only called fromGetOfferingDetails, never the converter.Impact. GCP CUD purchase happy-path is broken/useless; GCP recs silently filtered/mis-ranked. Money path.
Suggested fix. Extract vCPU count from the Recommender payload → set
rec.Count; thread the pricing path into the converter to fillCommitmentCost/OnDemandCost/SavingsPercentage/BreakEvenMonths. GuardbuildInsertRequest/PurchaseCommitmentto refuserec.Count <= 0. Also fix 10-M5 (per-service hardcoded PaymentOption — see #718/#829 for the monthly-stamp part). Regression test: realistic Recommender response → converter →Count > 0and VCPUAmountset; through scorer withMinSavingsPctset, GCP recs survive.References. Source: report 10 (C1, C2, M5) + architecture note on scorer contract. Related #264/PR #811 (RecurringMonthlyCost only), #718/PR #829 (payment-option monthly stamp).
Filed from automated adversarial code review (see docs/code-review/). Source finding(s): 10-C1, 10-C2, 10-M5.