fix(gcp): SKU lookup for Cloud SQL, Memorystore and Compute matches tier strings real descriptions may not contain #245

Summary

The GCP pricing extractors for Cloud SQL, Memorystore and Compute Engine find the SKU for a tier or machine type by searching the SKU's free-text Description for the tier or machine-type string. As far as I can tell from Google's published SKU descriptions, real Billing Catalog descriptions do not contain those strings, so real lookups would match nothing and return "no pricing found". The tests only use synthetic descriptions that were written to contain the token, so they cannot detect this.

Found in the independent review of #244 (a slice of #97). Related: #97, #244, #165.

Locations (main at be54dfa)

• providers/gcp/services/cloudsql/client.go:453-455 (skuMatchesTier, strings.Contains on sku.Description), used by extractSQLPricingFromSKUs :400; error at :362
• providers/gcp/services/memorystore/client.go:421-423 (skuMatchesTier), extractPricingFromSKUs :368; tiers hardcoded at :295-298 (BASIC, STANDARD_HA); error at :331
• providers/gcp/services/computeengine/client.go:1142-1144 (skuMatchesMachineType), extractComputePricingFromSKUs :1088; error at :1055
• SKUs are fetched with Services.Skus.List(serviceID) (cloudsql/client.go:108, memorystore/client.go:102, computeengine/client.go:340).

Failure scenario

Request pricing for Cloud SQL tier db-n1-standard-4 in us-central1. The extractor lowercases the description of each SKU and checks for db-n1-standard-4. Cloud SQL descriptions on Google's CUD-eligible SKU page look like:

• Cloud SQL for MySQL: Regional - 1 vCPU + 3.75GB RAM in Americas
• Cloud SQL for My SQL: Zonal - Enterprise Plus Performance Optimized C4A vCPU in Alabama

Neither contains a db-* tier token, so no SKU matches, both prices stay 0, and the caller gets no pricing found for Cloud SQL tier db-n1-standard-4. The same applies to Memorystore (the code's tiers are BASIC and STANDARD_HA, the pricing page lists capacity tiers such as M1 Basic and M1 Standard) and to Compute Engine (machine types such as n1-standard-4 are priced per vCPU and per GB of RAM, e.g. N1 Predefined Instance Core running in Americas, so a machine-type string would not appear).

This is the same before and after #244. #244 tightens the match to a whole token, which does not help if the token is absent from real descriptions.

Verified vs unverified

Verified on main:

• All three matchers test only sku.Description for the tier/machine-type string. No structured fields (Category.ResourceGroup, Category.UsageType, Category.ResourceFamily, ServiceDisplayName, PricingInfo[].PricingExpression.UsageUnit) are used to select the SKU.
• Every fixture is synthetic, e.g. Description: "db-n1-standard-1 Cloud SQL" (cloudsql/client_test.go:203), "Memorystore Redis STANDARD_HA" (memorystore/client_coverage_test.go, ~:196).
• No recorded real Billing Catalog response exists in the repo (no testdata directories; docs/design/gcp-spend-commitments.md has no SKU shapes).

Unverified:

• The real-data claim comes from description strings on Google's documentation pages (cloud.google.com/skus/sku-groups/cloud-sql-cud-eligible-skus and the pricing pages), not from a live Skus.List call. I used no credentials. The Compute SKU description forms were recalled, not checked. The API may return descriptions that differ from the docs page, and Category fields may also vary.
• Whether any real description contains the tier string by accident for some tiers.

Impact is therefore marked impact/few and severity medium pending a real catalog capture. If the claim holds, it becomes broader, and priority should be raised.

Acceptance criteria

1. Capture a recorded real Billing Catalog Skus.List response per service (Cloud SQL, Memorystore, Compute Engine), trimmed to relevant SKUs, committed as a fixture.
2. Match SKUs on structured fields (Category.ResourceGroup, Category.UsageType, ServiceDisplayName, pricing unit) plus the vCPU/RAM amounts described, instead of the tier/machine-type string in Description. Map tiers and machine types to vCPU/RAM (or Memorystore capacity tier) explicitly.
3. A test per service runs the extractor against the recorded real data and asserts a price for a known tier and region.
4. If the capture shows the current matching does work for some case, record that in the issue and close it with the fixture and test added.