Repository navigation
fix(cli): RDS ProjectedCoverage stays stale after --max-instances, count override or dedupe #2214
Description
After #2206, --max-instances, --count-override and the duplicate-RI dedupe re-derive ProjectedCoverage/ProjectedUtilization from the new Count. RDS is the exception: ProjectedCoverage is skipped on purpose (cmd/helpers.go refreshCountLinear), because family-NU sizing writes a family-wide aggregate (cloud-commitments-go recommendations/family_nu.go:320-340). Only RDS utilization is refreshed.
Scenario: an RDS recommendation sized with --target-coverage, then cut by --max-instances, still reports the family coverage it was originally sized for. That is the overstatement #1845 described, now limited to RDS. The impact is reporting only; purchases read Count.
A fix needs the family-NU pool context, which only the shared sizer has. Two options: re-run the family aggregate after count changes, or expose a re-derive helper from cloud-commitments-go.
Related: the ScaleRecommendationCosts doc comment in cloud-commitments-go (common/types.go:311-316) still says this is "tracked by #1845" and should point here.
Found during the independent review of #2206.
🤖 Generated with Claude Code
Activity
cristim commentedon Oct 17, 2026
Owner decision (2026-10-17): add a go-repo re-derive helper first. Filed as LeanerCloud/cloud-commitments-go#511. Marking status/blocked on it. [claude-cli-impl] will wire it in after it ships and the pin is bumped.