Repository navigation
fix(deps): adopt reviewed cloud-commitments-go purchase safeguards #35
Description
Confirmed release gap
Main go.mod still requires all four cloud-commitments-go modules (pkg, providers/aws, providers/azure, providers/gcp) at v0.0.0-20260928214714-ce9513612901, verified on 2026-09-30. It therefore does not select the subsequent GCP commitment-family dedupe, AWS reservation-state, ElastiCache engine-dedupe and purchase-cost fixes.
These coordinated old pins compile. The provider-only compilation failure was fixed in the library; upgrading that repository does not update the MCP consumer automatically.
References: library #154, merged provider pin/standalone CI PR #159, and P1 GCP duplicate-purchase issue #144.
Scope
Update the four requirements and corresponding sums together to published merged commit a32fd1a178e971ba48ae7469f5d472e6391c68e2, or a later independently reviewed canonical release containing it. Resolve and verify canonical public versions/source hashes. No replacements, vendoring, unrelated upgrades, source refactors or release automation. Add only regressions needed for consumer adoption; no cloud purchases or deployment.
Acceptance
- With the CI-pinned toolchain and GOWORK=off, record all four selected library versions with no replacements; tidy-diff, vet and pinned lint pass.
- Build the real MCP server target (
make buildor the repository's current server command) and run server/tools race-short tests. - Drive the actual MCP protocol with an in-process/fake-cloud harness, exercising tool registration, recommendation retrieval/filtering and purchase-result serialization. Recent matching GCP CUDs must suppress repeat recommendations; verify nullable versus explicit-zero purchase cost survives tool output and existing purchase/error guards remain intact.
- Prove an applicable consumer regression fails at the old pins and passes after upgrade. Do not execute live cloud purchases.
- Record independently reviewed SHA and verification. Treat packaging/release/deployment as separate status, not implied by merge.
Triage
P2 / medium / this-sprint / few / small: the dependency gap is confirmed, but this task has not reproduced an MCP-specific repeat purchase or established deployment exposure. The upstream P1 financial-risk fix needs adoption; raise this consumer's priority if protocol-path reproduction establishes the corresponding risk.
Activity
cristim commentedon Oct 7, 2026
claimed by cc-mcp-w3
cristim commentedon Oct 7, 2026
Filed #42 for a gap found while scoping this: the MCP consumer has no recfilter dedupe path (nothing imports pkg/recfilter; the search tool calls GetRecommendations directly), so the upstream GCP dedupe fix adopted here cannot suppress repeat recommendations at the MCP protocol level. The pin-sensitive regression for this issue will therefore cover the purchase-cost semantics at protocol level and the dedupe fix at the library boundary; wiring dedupe into the MCP search path is tracked separately in #42.
cristim commentedon Oct 7, 2026
Rollout relay for whoever lands this (claimed by cc-mcp-w3): cloud-commitments-go PR #218 —
fix(azure): stop dividing the monthly run-rate by the term months— merged upstream ase24345c(2026-10-07T13:01:38Z), after this issue was written. The fix lives inproviders/azure/internal/recommendations, so it is consumer-visible only via the module bump; any adoption PR should select providers/azure at or aftere24345c.Two constraints already verified on the consumer side:
v0.0.0-20261003204812-9962786e0695(newer than the other three). A single-SHA bump across all four modules at ane24345c-era commit could downgrade providers/aws — check each module's current pseudo-version timestamp before moving it.20261004143708-56555e1be095predatese24345c(compare: diverged, fix ahead by 62 commits). I've commented there suggesting it re-pin at/after the fix; whichever PR lands second should rebase/verify rather than duplicate the bump.cristim commentedon Oct 7, 2026
Correction to my comment above: the purchase-cost regression cannot be pin-sensitive at the MCP protocol level, because the purchase tool never sets CommitmentCost (gcpComputeEngineRecommendationFromArgs sets no price field, and the tool schema has none), so old and new library pins both serialize "cost":0 on that path. The pin-sensitive cost proof will instead sit at the library boundary (real computeengine client + fake CommitmentsService, CommitmentCost=1000: old pin fabricates "cost":1000, new pin reports explicit zero). The protocol-level harness still covers registration, retrieval/filtering, explicit-zero serialization, and the purchase guards, without a pin-sensitivity claim.
Also: per the fleet relay, this bump will pin providers/azure at e24345ce68f82ef960315300b680c1d1858627cf (library #218, the monthly run-rate fix, verified on main and containing a32fd1a) rather than at a32fd1a itself.
cristim commentedon Oct 7, 2026
Consumer-impact assessment for two more upstream merges, both relayed by the PR-fleet orchestrator and verified against this repo's call graph:
go#207 (
58c25f0, Azure savings plans GetExistingCommitments now fail-closed) — no consumer-side change needed. This repo has no live call path to AzureGetExistingCommitments: the only reference is the test fake in tools/purchase_test.go:79;recfilter.DuplicateChecker(which already propagates the error fail-closed at pkg/recfilter/dedupe.go:44) is not used by the MCP server; and the pinned savingsplansPurchaseCommitment(services/savingsplans/client.go:247) does not call it internally. The new hard-error can only reach callers of that method on the next pin bump, and this repo has none — so noerror treated as empty inventory → duplicate purchasehazard exists here today. Worth a regression note in the adoption PR anyway: if a future MCP tool ever surfaces existing-commitment inventory, the error must propagate, never map to empty.go#205 (
aa903fe, GCP Cloud Storage recommendation contract) — no action needed. The repo pins providers/gcp but its only GCP surface is Compute Engine CUDs (tools/gcp_computeengine_cud.go); no Cloud Storage paths, noRecommenderClient/GetRecommendationsForServicecalls (the one grep hit is a comment in tools/search_recommendations.go:239). Purely additive upstream; arrives with the next per-module gcp pin bump.Both land naturally with the per-module pins this issue tracks; nothing here warrants an independent consumer PR.
test(gcp): cover adopted purchase safeguards in MCP consumer (#43)
cristim commentedon Oct 8, 2026
Merged consumer regression coverage in #43, squash commit 76f0d39, reviewed head 4dac95a. The provider adoption was already present through #39; no provider version was downgraded.
Verification: independent adversarial review, old-pin red/new-pin green library regressions, a real in-process MCP purchase path with a fake cloud service and exactly one Insert, and a mutation that bypasses the purchase which now fails. Fresh build, full nonshort race suite and pinned lint passed. The actual merged tree matches the independently validated combined tree. Post-merge Build & Test and pre-commit passed.
The protocol recommendation-retrieval/filtering acceptance item remains unfinished and is tracked in #42. The new dedupe test exercises the real library boundary, not production MCP search filtering. #35 must remain open until that protocol path is implemented and verified. GitHub auto-closed it immediately after #43 merged despite the final PR body using Refs; that closure has been corrected.
CR waived: quota, adversarial review + local verification + green CI. The returned Insert-call finding was fixed and independently proven; final-head CR coverage was throttled and is tracked for retrospective review when quota returns.
Evidence uses realistic local fixtures, without a live-cloud purchase or exchange. No deployment or packaged-release acceptance is claimed.
Evidence marker: cc-mcp-pr43-76f0d395-issue35-postmerge-20261008.
cristim commentedon Oct 9, 2026
Acceptance mapping, verified live on main 87ecc84 (build, vet,
go test -shortfor ./tools ./cmd/... . and golangci-lint all pass; noreplacelines):go build ./...and the short suites pass on main.One item is NOT met literally: "Recent matching GCP CUDs must suppress repeat recommendations". #53 deliberately only flags GCP (
possibly_covered), because the library's GCP hook defers a whole machine family when any recent CUD exists (2 vCPU bought would hide a 64 vCPU recommendation). Leaving this open until the owner decides whether flag-only satisfies the acceptance or a count-aware GCP check is wanted (library change).