fix(elasticache): dedupe missing engines and redis valkey family - #158
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: LeanerCloud/cloud-commitments-go/.coderabbit.yaml Review profile: CHILL Plan: Essentials Run ID: 📒 Files selected for processing (6)
💤 Files with no reviewable changes (1)
Included review availability: This review used your included allowance. 0 included reviews remain after this review. Your included PR review attempts over the past 7 days set your current allowance at 1 review per hour. 📝 WalkthroughWalkthroughAWS ElastiCache deduplication now matches Redis and Valkey recommendations under one engine identity. Empty reservation engines act as wildcards. Matching commitments are consumed against recommendation counts, and AWS reservation and parser tests cover these cases. ChangesAWS commitment deduplication
Priority: ⬇️ Low Estimated code review effort: 3 (Moderate) | ~20 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to No actionable issue is established; the change is ready for normal merge checks. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Comment |
Summary
Recent ElastiCache reservations now suppress matching Redis and Valkey recommendations even when AWS omits the reservation engine. Unknown engines match conservatively and emit a warning. Known Memcached reservations remain separate.
Root cause and fix
The duplicate checker used exact engine keys, so an empty engine or Redis reservation could never match a Valkey recommendation. AWS ElastiCache now has dedupe-only engine keys, scoped to both supported service aliases. Exact family counts are consumed before unknown-engine counts, with each count deducted once. Recommendation engines and purchase offering parameters remain unchanged.
The MemoryDB regression now obtains its recommendation through the real CE parser instead of hardcoding the parser's expected engine.
Regression proof
New count-budget and parser-to-SDK-client tests fail on the original production code at the expected suppression assertions, then pass with this fix. Cases cover missing engines, Redis/Valkey case variants, Memcached separation, partial counts, repeated rows, same-key wildcard matching, and mixed provider/service collections in both orders. A mutation of only the MemoryDB parser engine makes its relocated regression fail. An independent reviewer reproduced these failures and restored the changes before passing the suites.
Verification
GOWORK=off go mod tidy -diffchecks were empty.9b5ca4d61d2afe05ffca9109244dc225820297ef. This session explicitly uses that reviewer because the pinned Opus model is unavailable. CI remains a merge gate.Evidence uses real library paths with injected SDK fixtures, not live cloud calls. Standalone AWS compilation remains blocked by the inherited published-pkg
PurchaseResult.Costmismatch tracked in #154. Workspace module resolution was verified; no dependency overrides were added.Main
a29ea574e5223cc05ec1cbef28865f5bc1a2496a, including #155, #156 and #157, was integrated with a normal merge that preserves published history. The resolution retains both the GCP dispatch and ElastiCache test groups, plus the MemoryDB recfilter import required by #156. Combined uncached race tests passed across shared recfilter, AWS recommendations/ElastiCache/MemoryDB and GCP computeengine; build, vet, pinned lint and applicable hooks passed. The independent reviewer re-read the committed resolution and passed named AWS/GCP/shared regressions in those five packages at the exact integrated SHA.Labels mirror #150; the issue does not carry
triaged.Closes #150
Summary by CodeRabbit