Summary
Purchased RDS RIs get a generic reservation ID like rds-db-t4g-medium-1779308829 instead of the descriptive name (ri-<account>-rds-<engine>-<region>-<class>-<count>x-<pct>-<ts>-<uuid>) that generatePurchaseID produces and that older reservations carry (e.g. rds-cxm-trading-aurora-mysql-db-t4g-medium-us-east-1-1x-50pct-...).
Root cause
Two issues:
-
Descriptive ID never reaches AWS. executePurchase (cmd/multi_service_helpers.go) calls PurchaseCommitment first, then assigns generatePurchaseID(...) to result.CommitmentID only as a display value. PurchaseCommitment (providers/aws/services/rds/client.go) generates its own ReservedDBInstanceId via fmt.Sprintf("rds-%s-%d", rec.ResourceType, time.Now().Unix()), so AWS records the generic name.
-
Engine missing from the descriptive ID. generatePurchaseID's Details type switch only handles value types (common.DatabaseDetails), but both the live parser and the CSV loader store pointers (*common.DatabaseDetails) — findOfferingID requires the pointer form. So engine comes out empty and the descriptive ID drops the engine segment.
Fix
- Add a reservation-ID field to
common.PurchaseOptions; have executePurchase compute the descriptive ID up front and pass it in.
PurchaseCommitment uses opts's descriptive ID (run through common.SanitizeReservationID) as ReservedDBInstanceId when set, falling back to the current generic form otherwise.
- Make
generatePurchaseID handle pointer Details (*DatabaseDetails / *CacheDetails / *ComputeDetails) as well as value, mirroring extractEngine.
Impact
Cosmetic but operationally useful: descriptive reservation IDs make RIs identifiable by account/engine/region/size in the AWS console and billing, matching the existing fleet's naming. No change to what is purchased.
Summary
Purchased RDS RIs get a generic reservation ID like
rds-db-t4g-medium-1779308829instead of the descriptive name (ri-<account>-rds-<engine>-<region>-<class>-<count>x-<pct>-<ts>-<uuid>) thatgeneratePurchaseIDproduces and that older reservations carry (e.g.rds-cxm-trading-aurora-mysql-db-t4g-medium-us-east-1-1x-50pct-...).Root cause
Two issues:
Descriptive ID never reaches AWS.
executePurchase(cmd/multi_service_helpers.go) callsPurchaseCommitmentfirst, then assignsgeneratePurchaseID(...)toresult.CommitmentIDonly as a display value.PurchaseCommitment(providers/aws/services/rds/client.go) generates its ownReservedDBInstanceIdviafmt.Sprintf("rds-%s-%d", rec.ResourceType, time.Now().Unix()), so AWS records the generic name.Engine missing from the descriptive ID.
generatePurchaseID'sDetailstype switch only handles value types (common.DatabaseDetails), but both the live parser and the CSV loader store pointers (*common.DatabaseDetails) —findOfferingIDrequires the pointer form. Soenginecomes out empty and the descriptive ID drops the engine segment.Fix
common.PurchaseOptions; haveexecutePurchasecompute the descriptive ID up front and pass it in.PurchaseCommitmentusesopts's descriptive ID (run throughcommon.SanitizeReservationID) asReservedDBInstanceIdwhen set, falling back to the current generic form otherwise.generatePurchaseIDhandle pointerDetails(*DatabaseDetails/*CacheDetails/*ComputeDetails) as well as value, mirroringextractEngine.Impact
Cosmetic but operationally useful: descriptive reservation IDs make RIs identifiable by account/engine/region/size in the AWS console and billing, matching the existing fleet's naming. No change to what is purchased.