perf(azure compute): add vCPU + MemoryGB to ComputeDetails and wire batched SKU catalogue

[cristim]

Summary

Follow-up to PR #81 (perf(azure): batched SKU catalogue lookup eliminates N+1 in recommendation converters), which closed #49 for cache / cosmosdb / database but explicitly scoped back compute.

The two enrichments the SKU catalogue would supply for compute are vCPU and MemoryGB, sourced from armcompute.ResourceSKUsClient.ListByLocation(region) → ResourceSKU.Capabilities. Neither has a field on common.ComputeDetails (pkg/common/types.go) to write into — the struct currently exposes only InstanceType, Platform, Tenancy, Scope. Adding new fields touches every cloud provider (AWS, Azure, GCP) + every consumer (frontend rendering, common matchers, snapshot/golden tests), which is well outside the scope of an Azure perf change.

Current behaviour

providers/azure/services/compute/client.go::convertAzureVMRecommendation (line ~703) builds common.ComputeDetails{InstanceType: f.ResourceType} only. The function godoc (post-#81) explicitly explains the scope decision and points back here.

Expected behaviour

Full ComputeDetails population: vCPU, MemoryGB, plus the existing InstanceType / Platform / Tenancy / Scope. UI tables render the actual instance shape instead of just the SKU name.

Proposed fix

Three-step refactor, ideally as separate atomic commits in a single PR:

1. Extend common.ComputeDetails: add VCPU int + MemoryGB float64. JSON tags consistent with existing fields. Update Go-side consumers (matchers, frontend type bindings via pkg/common → frontend types.ts).
2. Update AWS + GCP converters: populate the new fields where the SDK already exposes them (AWS DescribeInstanceTypes, GCP MachineType).
3. Wire Azure: port the same lazy cachedSKULookup pattern from cache/cosmos/database into compute/client.go, hitting armcompute.ResourceSKUsClient.NewListPager(region) once per client lifetime, mapping ResourceSKU.Name → {VCPU, MemoryGB}. Converter reads from the cache and falls back to zero on miss.

Test plan

• Per-converter unit tests for AWS/Azure/GCP: SKU catalogue / instance-type cache returns known {vCPU, memoryGB} → assert Details.VCPU and Details.MemoryGB are populated. Catalogue fetch error → fields stay 0, conversion succeeds.
• Pin the perf invariant in Azure: _CachedSKULookup_FetchedOnce analogue, multiple converter calls hit the catalogue once.
• Snapshot/golden-test updates for any frontend rendering that exposes the new fields.

References

• Closed-for-3-services parent: perf(azure): batched SKU catalogue lookup to populate deferred Details fields without N+1 API calls #49
• Lands-the-pattern PR: perf(azure): batched SKU catalogue lookup eliminates N+1 in recommendation converters #81
• Files:
  • pkg/common/types.go::ComputeDetails
  • providers/azure/services/compute/client.go::convertAzureVMRecommendation
  • providers/aws/services/compute/... (mirror)
  • providers/gcp/services/compute/... (mirror)
  • frontend/src/types.ts (renderer types)
• Known-issue doc: known_issues/10_azure_provider.md → "MEDIUM: Azure compute Details vCPU/MemoryGB require ComputeDetails type extension"

Severity

Medium — UI degrades to "unknown" for vCPU/memory on Azure compute recs (and presumably AWS/GCP if they also leave the field empty pending the type extension).

Effort

Medium — type extension is mechanical but cross-cutting (3 providers, frontend, matchers, snapshot tests). Wiring the Azure SKU cache itself is ~30 LOC mirroring cache/cosmos/database.

[cristim]

P2: cross-cutting type extension required before Azure (and potentially AWS/GCP) compute recommendations can show vCPU/MemoryGB in the UI. Touches 3 providers + frontend types + snapshot tests — M effort. The Azure SKU catalogue pattern is already established by PR #81 for cache/cosmos/database; compute wiring mirrors that pattern. (triage agent wave1-C)

[cristim]

Verification (post-merge of #81)

Confirming this issue is partially addressed — recommend keep open as scoped follow-up.

What I checked on feat/multicloud-web-frontend

Step 1 — Extend common.ComputeDetails: DONE.
pkg/common/types.go now has both fields:

type ComputeDetails struct {
    InstanceType string  `json:"instance_type"`
    Platform     string  `json:"platform"`
    Tenancy      string  `json:"tenancy"`
    Scope        string  `json:"scope"`
    VCPU         int     `json:"vcpu,omitempty"`      // 0 = unknown
    MemoryGB     float64 `json:"memory_gb,omitempty"` // 0 = unknown
}

GetDetailDescription already renders the size suffix when both fields are populated.

Step 3 — Wire Azure batched SKU catalogue: NOT DONE.
providers/azure/services/compute/client.go::convertAzureVMRecommendation (line ~707) still builds:

Details: common.ComputeDetails{
    InstanceType: f.ResourceType,
},

No cachedSKULookup from armcompute.ResourceSKUsClient. The N+1-eliminator pattern from cache/cosmos/database has not been mirrored into compute.

Step 2 — AWS/GCP populate the new fields: not separately verified in this pass.

Verdict

Type extension landed; the Azure wiring (the perf payoff) and the test plan (_PopulatesVCPUMemoryFromSKUCache, _CachedSKULookup_FetchedOnce for compute) remain. Recommend keep open with the title narrowed to "wire batched SKU catalogue + populate VCPU/MemoryGB on Azure compute" since the type-extension half is done.