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

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:

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).
Update AWS + GCP converters: populate the new fields where the SDK already exposes them (AWS DescribeInstanceTypes, GCP MachineType).
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.

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)

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.

feat(azure compute): populate vCPU + MemoryGB via cached SKU catalogue (

Verified resolved by PR #229.

PR feat(azure compute): populate vCPU + MemoryGB via cached SKU catalogue (closes #148) #229 merged 2026-05-03 with title feat(azure compute): populate vCPU + MemoryGB via cached SKU catalogue (closes #148), explicitly closing this issue.
The old convertAzureVMRecommendation godoc comment ("Compute is NOT yet wired...") is replaced by code that calls cachedSKULookup and populates Details.VCPU / Details.MemoryGB when both are >0.
A new vmSKUEntry struct + skuCacheOnce sync.Once + skuCacheMap on ComputeClient implement the lazy single-fetch pattern from PR perf(azure): batched SKU catalogue lookup eliminates N+1 in recommendation converters #81, ported to compute as the issue proposed.
convertAzureVMRecommendation signature updated from (_ context.Context, ...) to (ctx context.Context, ...) — the catalogue fetch is threaded through correctly.
Graceful-degradation contract satisfied: catalogue-fetch failure leaves VCPU/MemoryGB at 0 (omitempty JSON tags hide them), conversion does not fail, WARN logged once.
4 new unit tests added: cache-hit enrichment, pager-error fallback, cache-miss zero-value, and the N+1 invariant (_CachedSKULookup_FetchedOnce). All 42 tests in the package pass.
Prerequisites already in place: PR perf(common): extend ComputeDetails with VCPU + MemoryGB #97 added VCPU / MemoryGB fields to common.ComputeDetails; PR perf(azure): batched SKU catalogue lookup eliminates N+1 in recommendation converters #81 landed the cache pattern for the other three Azure services.

Recommending closure.

Sunbelt Computer Software

PL/B Language Development and Support

Navigation Menu

Repository navigation

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

Summary

Current behaviour

Expected behaviour

Proposed fix

Test plan

References

Severity

Effort

Verification (post-merge of #81)

What I checked on `feat/multicloud-web-frontend`

Verdict

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Sunbelt Computer Software

PL/B Language Development and Support

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

Description

Summary

Current behaviour

Expected behaviour

Proposed fix

Test plan

References

Severity

Effort

Activity

cristim commented on Apr 28, 2026

cristim commented on Apr 30, 2026

Verification (post-merge of #81)

What I checked on feat/multicloud-web-frontend

Verdict

cristim commented on May 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

What I checked on `feat/multicloud-web-frontend`