The Compute Engine recommendation converter can combine a VCPU amount for commitment A with a MEMORY amount for commitment B into one recommendation. Follow-up to #80 / #163. This occurs in conversion, separately from #61's unused GroupCommitments aggregation and #60's commitment-type extraction.
At commit 4c298ec7bfcbec4d41fa37922e6d0591a7fbfb7f, the CPU and memory extractors scan operations independently. Neither correlates the selected CPU and memory operation's Resource. The Recommender Operation contract identifies each operation's target resource; operation groups can contain operations on multiple resources.
Local reproduction in package computeengine using the existing synthetic fixture:
input := commitmentOnlyCUDRecommendation()
input.Content.OperationGroups[0].Operations[1].Resource += "-other"
rec, err := (&Client{}).convertGCPRecommendation(context.Background(), input, common.RecommendationParams{})
amount, memoryErr := memoryMBFromDetails(*rec)Observed: err=nil, Count=4, amount=6144, memoryErr=nil, although CPU targets .../commitments/cud-001 and memory targets .../commitments/cud-001-other. The same-resource control returns the same quantities. The converted recommendation has paired amounts that did not describe one commitment in the input.
Evidence scope: local converter test at the exact commit, using generic-contract synthetic data. No evidence that the current service emits this arrangement, and no actual wrong purchase was demonstrated. The fixture has no machine type and the existing machine-type gate already prevents its purchase independently.
Acceptance: preserve coherent same-resource quantities; explicitly reject ambiguous cross-resource combinations or produce separately coherent recommendations if a demonstrated caller requires that behavior. Test resource identity and operation-group boundaries through the public SDK/provider path. Do not infer a service-specific format from this fixture.
Dedup checked #60, #61, #105, #52 plus all-state memory and cross-resource searches. Triage: medium severity for demonstrated incorrect recommendation data, limited demonstrated impact, this quarter, medium effort, P2. Live service frequency and downstream purchase reachability remain unproven.
The Compute Engine recommendation converter can combine a VCPU amount for commitment A with a MEMORY amount for commitment B into one recommendation. Follow-up to #80 / #163. This occurs in conversion, separately from #61's unused GroupCommitments aggregation and #60's commitment-type extraction.
At commit
4c298ec7bfcbec4d41fa37922e6d0591a7fbfb7f, the CPU and memory extractors scan operations independently. Neither correlates the selected CPU and memory operation'sResource. The Recommender Operation contract identifies each operation's target resource; operation groups can contain operations on multiple resources.Local reproduction in package computeengine using the existing synthetic fixture:
Observed: err=nil, Count=4, amount=6144, memoryErr=nil, although CPU targets
.../commitments/cud-001and memory targets.../commitments/cud-001-other. The same-resource control returns the same quantities. The converted recommendation has paired amounts that did not describe one commitment in the input.Evidence scope: local converter test at the exact commit, using generic-contract synthetic data. No evidence that the current service emits this arrangement, and no actual wrong purchase was demonstrated. The fixture has no machine type and the existing machine-type gate already prevents its purchase independently.
Acceptance: preserve coherent same-resource quantities; explicitly reject ambiguous cross-resource combinations or produce separately coherent recommendations if a demonstrated caller requires that behavior. Test resource identity and operation-group boundaries through the public SDK/provider path. Do not infer a service-specific format from this fixture.
Dedup checked #60, #61, #105, #52 plus all-state memory and cross-resource searches. Triage: medium severity for demonstrated incorrect recommendation data, limited demonstrated impact, this quarter, medium effort, P2. Live service frequency and downstream purchase reachability remain unproven.