Summary
The memory selector matches positively on a memory path filter, but the vCPU selector matches by exclusion: any commitment operation whose path contains 'amount' and is not a memory op is returned as the vCPU count, first match wins. A recommendation carrying an accelerator or local-SSD amount therefore yields that amount as the count, and the count is what commitment grouping sums into the purchased vCPU total. The grouped sibling is the fallback below it, which takes the count from an untyped numeric value in the recommendation overview blob when no vCPU operation is found.
Location
providers/gcp/services/computeengine/client.go:1296providers/gcp/services/computeengine/client.go:1333 (A08b-031)
All at 3c0f8ac94048a2c36fce5ccddee54e6c4849a5cd
Failure scenario
memoryMBFromOperationGroups selects positively (isMemoryAmountOp true), but vcpuCountFromOperationGroups selects by exclusion: any commitment operation whose path contains "amount" and whose path filter is not MEMORY is returned as the vCPU count. A recommendation carrying an ACCELERATOR or LOCAL_SSD amount op (and accelerator families are exactly the ones familyRequiredResource exists to describe) returns that amount as rec.Count. The count is what GroupCommitments sums into the purchased vCPU total, so the resulting CUD commits to the wrong number of vCPUs. Ordering decides which wins, since the first match returns.
The same defect appears at:
A08b-031: vCPU count falls back to an untyped numericValue from the recommendation overview blob
Evidence
if !strings.Contains(strings.ToLower(op.GetPath()), "amount") {
continue
}
if isMemoryAmountOp(op) {
continue
}
if v := op.GetValue(); v != nil {Suggested fix
Give the vCPU selector its own positive path-filter test for VCPU, mirroring isMemoryAmountOp, and error when the payload carries an amount op of an unhandled resource type.
Found by the 2026-09-02 codebase audit, finding A08b-030, reported by one reviewer and independently confirmed by a second. Full report: docs/audits/codebase-audit-2026-09-02.md.
Summary
The memory selector matches positively on a memory path filter, but the vCPU selector matches by exclusion: any commitment operation whose path contains 'amount' and is not a memory op is returned as the vCPU count, first match wins. A recommendation carrying an accelerator or local-SSD amount therefore yields that amount as the count, and the count is what commitment grouping sums into the purchased vCPU total. The grouped sibling is the fallback below it, which takes the count from an untyped numeric value in the recommendation overview blob when no vCPU operation is found.
Location
providers/gcp/services/computeengine/client.go:1296providers/gcp/services/computeengine/client.go:1333(A08b-031)All at 3c0f8ac94048a2c36fce5ccddee54e6c4849a5cd
Failure scenario
memoryMBFromOperationGroupsselects positively (isMemoryAmountOptrue), butvcpuCountFromOperationGroupsselects by exclusion: any commitment operation whose path contains "amount" and whose path filter is not MEMORY is returned as the vCPU count. A recommendation carrying anACCELERATORorLOCAL_SSDamount op (and accelerator families are exactly the onesfamilyRequiredResourceexists to describe) returns that amount asrec.Count. The count is whatGroupCommitmentssums into the purchased vCPU total, so the resulting CUD commits to the wrong number of vCPUs. Ordering decides which wins, since the first match returns.The same defect appears at:
A08b-031: vCPU count falls back to an untypednumericValuefrom the recommendation overview blobEvidence
Suggested fix
Give the vCPU selector its own positive path-filter test for
VCPU, mirroringisMemoryAmountOp, and error when the payload carries an amount op of an unhandled resource type.Found by the 2026-09-02 codebase audit, finding
A08b-030, reported by one reviewer and independently confirmed by a second. Full report:docs/audits/codebase-audit-2026-09-02.md.