Severity: a GCP "purchase" creates new billable infrastructure instead of buying a commitment
Three GCP PurchaseCommitment implementations do not buy a committed-use discount — they provision a brand-new billable resource:
providers/gcp/services/cloudsql/client.go:237 — InsertInstance with PricingPlan:"PACKAGE" creates a NEW Cloud SQL instance sql-committed-<ts>.providers/gcp/services/cloudstorage/client.go:249 — creates a NEW empty bucket storage-committed-<ts> (GCS has no CUD purchase API at all).providers/gcp/services/memorystore/client.go:193 — creates a NEW Redis instance redis-committed-<ts>.
(GCP Compute is correct — it calls the real RegionCommitments.Insert.)
Reachability
CloudStorage (google.storage.bucket.CostRecommender) and Memorystore (google.memorystore.redis.PerformanceRecommender) both return recommendations and are exposed via GCPProvider.GetServiceClient (providers/gcp/.../provider.go:434, ServiceStorage/ServiceCache). So a user can select one of these recs, approve it, and the "purchase" silently spins up a new DB / bucket / Redis instance — ongoing cost, and not the commitment they asked for.
Impact
- Spends money on the wrong thing (new infra), with recurring cost.
- The "commitment" the user believes they bought does not exist.
- For CloudSQL/Memorystore the orphaned instance keeps billing until someone notices.
Fix
For each of these three services, either:
- Implement the real CUD purchase where one exists (Cloud SQL has committed-use; Memorystore does not have a standalone CUD API), or
- If no purchasable commitment exists for that service (e.g. GCS), make
PurchaseCommitment return a clear "not supported" error and stop generating purchasable recs for it (recs should be advisory-only / non-selectable).
Add a regression test asserting PurchaseCommitment for these services does NOT call any resource-creation API.
Dedup
Not covered by #264 (RecurringMonthlyCost parsing), #247 (perms), #251 (mock harness), or the Azure-parity cluster. This is a GCP executor-semantics defect. Surfaced in the full purchase-workflow trace.
Severity: a GCP "purchase" creates new billable infrastructure instead of buying a commitment
Three GCP
PurchaseCommitmentimplementations do not buy a committed-use discount — they provision a brand-new billable resource:providers/gcp/services/cloudsql/client.go:237—InsertInstancewithPricingPlan:"PACKAGE"creates a NEW Cloud SQL instancesql-committed-<ts>.providers/gcp/services/cloudstorage/client.go:249— creates a NEW empty bucketstorage-committed-<ts>(GCS has no CUD purchase API at all).providers/gcp/services/memorystore/client.go:193— creates a NEW Redis instanceredis-committed-<ts>.(GCP Compute is correct — it calls the real
RegionCommitments.Insert.)Reachability
CloudStorage (
google.storage.bucket.CostRecommender) and Memorystore (google.memorystore.redis.PerformanceRecommender) both return recommendations and are exposed viaGCPProvider.GetServiceClient(providers/gcp/.../provider.go:434,ServiceStorage/ServiceCache). So a user can select one of these recs, approve it, and the "purchase" silently spins up a new DB / bucket / Redis instance — ongoing cost, and not the commitment they asked for.Impact
Fix
For each of these three services, either:
PurchaseCommitmentreturn a clear "not supported" error and stop generating purchasable recs for it (recs should be advisory-only / non-selectable).Add a regression test asserting
PurchaseCommitmentfor these services does NOT call any resource-creation API.Dedup
Not covered by #264 (RecurringMonthlyCost parsing), #247 (perms), #251 (mock harness), or the Azure-parity cluster. This is a GCP executor-semantics defect. Surfaced in the full purchase-workflow trace.