Repository navigation
fix(aws/ec2): reject unrecognized RI term instead of silently defaulting to 1yr (follow-up to #1207) - #1481
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 6 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
…ing to 1yr getDurationValue fell through to OneYearSeconds for any unrecognized or empty term string, missed by PR #1207's ARCH-04 sweep of the other five provider term converters. A malformed term (e.g. an empty string from a 0/NULL Term DB row on the scheduler purchase path) would silently buy a real 1-year EC2 RI instead of erroring, the same money-risk pattern #1207 fixed everywhere else. Mirror the whitelist-switch idiom used by the RDS/ElastiCache/MemoryDB/Redshift/OpenSearch converters: return an explicit error on anything outside 1yr/1/3yr/3 and propagate it through buildEC2QueryFromRec so findOfferingID aborts before any AWS API call.
… defaulting to 3yr convertRecommendations coerced an empty or unparseable rec.Term to a Term=3 RecommendationRecord, logging only a warning (and nothing at all for an empty string). rec.Term round-trips through this int on the purchase path (internal/purchase/execution.go formats it back as "%dyr"), so the fabricated default let a malformed term launder into a real, purchasable 3-year commitment, bypassing every provider client's ARCH-04 term whitelist entirely since "3yr" is itself a valid value those whitelists accept. Drop the recommendation instead, with an ERROR-level log identifying the offending rec, rather than persisting a fabricated term.
37bd810 to
18d49cc
Compare
|
@coderabbitai review |
✅ Action performedReview finished.
|
Summary
Follow-up to #1207 (ARCH-04): that PR fixed five provider term converters
(elasticache, rds, memorydb, redshift, opensearch) that silently defaulted
an unrecognized/malformed RI/SP term string to a valid duration instead of
erroring. Its inventory missed a sixth converter with the exact same bug,
plus a related issue one step upstream of all six.
1.
providers/aws/services/ec2/client.go:getDurationValueAny unrecognized or empty term (including an empty string produced by a
0/NULL
TermDB row on the scheduler purchase path) silently fell throughto
OneYearSeconds, feeding intobuildEC2QueryFromRec->findOfferingID->
PurchaseCommitmentand buying a real 1-year EC2 RI instead of erroring.The existing test even asserted this fallback as intended behavior. Fixed
by mirroring the whitelist-switch idiom from the five already-fixed
converters:
getDurationValuenow returns(int64, error)and rejectsanything outside
1yr/1/3yr/3, with the error propagated up throughbuildEC2QueryFromRec.2.
internal/scheduler/scheduler.go:convertRecommendationsAn empty or unparseable
rec.Termwas silently coerced toTerm: 3whenpersisting the
RecommendationRecord(only a warn-log for a parsefailure, no log at all for an empty string).
rec.Termround-tripsthrough this int on the purchase path
(
internal/purchase/execution.goformats it back as"%dyr"), so thislet a malformed term launder into a valid, purchasable 3-year commitment
upstream of every provider client's ARCH-04 whitelist -- those
whitelists can never catch it, because
"3yr"is itself one of thevalues they accept. Fixed by dropping the recommendation (skip
persisting it) with a clear ERROR-level log instead of fabricating a
term.
Testing
go build ./...-- clean (exit 0)go vet ./...-- clean (exit 0)go test ./providers/aws/... ./internal/scheduler/...-- all packagesok(exit 0);internal/schedulerincludes the newTestScheduler_ConvertRecommendations_InvalidTermDroppedregressiontest, which fails on the pre-fix code (asserts the batch drops both a
blank-term and a garbage-term rec while keeping a valid one) and
passes on the fix
go test ./...(full suite, root module) -- allok, no failuresgolangci-lint v2.10.1(exact CI pin) run exactly as CI invokes it(
golangci-lint run --timeout=10m, no path args) -- 0 issues on thisbranch
gocyclo -over 10 -ignore "_test\.go" .(exact CI invocation) -- nofunctions over the threshold
Note on CI coverage
While reproducing CI's exact lint/vet/test invocations to verify this
fix, I found that
go vet ./..., the unit-test step, theintegration-test step, and golangci-lint in
ci.ymlall run bare./...from the repo root, which in this multi-module (go.work)layout only covers the root module --
providers/aws(where the EC2fix in this PR lives),
providers/azure,providers/gcp,pkg, andtests/e2eare silently skipped by all four checks. Onlygovulncheckand
gosecalready loop per-module correctly. Filed as #1478; notfixed here to keep this PR scoped to the ARCH-04 follow-up. All
verification above for the
providers/aws/services/ec2changes wasdone locally with the exact CI-pinned toolchain since CI itself
currently can't verify that module.
Closes: follow-up to #1207