Repository navigation
fix(gcp): recTotalCommitment counts GCP recommendations at about 2x (spend caps too strict) #683
Description
Found while tracing consumers for PR #671 (not caused by it).
For GCP the scheduler stores UpfrontCost = rec.CommitmentCost (term total, internal/scheduler/scheduler.go:1582) and MonthlyCost = rec.RecurringMonthlyCost, which the GCP provider sets to CommitmentCost / termMonths (library convertGCPRecommendation). recTotalCommitment (internal/api/handler_purchases.go:2642) = UpfrontCost + MonthlyCost * Term * 12, so a GCP recommendation counts about 2x its real commitment against MaxPurchaseAmount caps. GCP CUDs have no upfront charge.
Effect: caps are stricter than intended for GCP (purchases that fit the cap are denied), so lower severity than an under-count. Also execution.TotalUpfrontCost (internal/purchase/execution.go:689,993) and approval emails show the term total as "upfront" for GCP.
Fix direction: store GCP recommendation UpfrontCost as 0 (term total lives in CommitmentCost/monthly), or special-case in recTotalCommitment; needs a decision on the stored-row semantics and the stale rows already stored.
Activity
IAmJSD commentedon Oct 19, 2026
Claiming: working on this
IAmJSD commentedon Oct 19, 2026
Already fixed on main through the GCP provider bump in #976 (d496f38), which brought in go#408 (Cloud SQL/Memorystore, a3fb251) and go#381 (Compute Engine, 309cb5c). Neither referenced this issue, so it stayed open.
The GCP converters now leave
CommitmentCostat 0, so only the monthly cost carries the commitment, andTotalCommitment()(UpfrontCost+MonthlyCost × Term × 12) equals the commitment price exactly. The pinned library's own GCP tests confirmCommitmentCost == 0and that upfront plus monthly × term equals the commitment, for all three services.What's left only errs on the strict side:
TotalUpfrontCostand approval emails still show the term total.