You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(azure): list Azure Redis recommendations under managedredis (ServiceMemoryDB), the only buyer after #538 #692
After #538 (option A), only managedredis (ServiceMemoryDB) buys Azure Redis reservations, and cache.PurchaseCommitment refuses. But the Azure recommendations adapter still emits every Redis recommendation labelled ServiceCache, so a consumer that routes purchases by rec.Service reaches the cache client and is always refused.
Current behaviour
Aggregate collection:providers/azure/recommendations.go collects Redis recommendations only through newCacheClientFn (the "Cache (Redis) recommendations" block). cache.convertAzureRedisRecommendation labels them common.ServiceCache.
Advisor: it maps reservedResourceTyperediscache to ServiceCache (serviceFromExtendedProperties), and priceAdvisor prices ServiceCache through the cache client (recommendations_advisor_pricing.go).
Purchase routing:provider.goGetServiceClient(ServiceCache) returns the cache client.
Steps to verify the gap
Get Azure recommendations through RecommendationsClientAdapter for a subscription with Redis reservation recommendations.
Route a Redis recommendation through GetServiceClient(rec.Service) and call PurchaseCommitment.
It returns an error wrapping common.ErrRefusedBeforePurchase ("purchased through the memorydb service").
Expected behaviour
Each Azure Redis recommendation is listed once, under the service that can buy it.
Proposed fix
Collect Redis through managedredis (labelled ServiceMemoryDB) instead of cache, in the aggregate fan-out and the service filter.
Map Advisor rediscache to ServiceMemoryDB, and price it through managedredis.
Tests: aggregate Redis recommendations carry ServiceMemoryDB; an Advisor rediscache row is labelled and priced as managedredis.
Consumer note: the platform and CLI must read Azure Redis recommendations under memorydb, and stored cache rows stop refreshing.
References
Parent: #538 (owner decision option A), and the PR that implements it. Related: #47.
Severity: medium. Azure Redis purchases are blocked through the default routing until this lands. Nothing is bought twice.
Claimed by claude-cc-libs: planning (read-only) how Azure Redis recommendations get labelled and routed to managedredis (ServiceMemoryDB) instead of the cache client that now refuses, covering aggregate collection, Advisor mapping and pricing. Two review passes on the plan before any code. Builds run under the current load throttle.
Fix. managedredis becomes the only Azure Redis producer, in aggregate collection, the Advisor rediscache mapping and Advisor pricing. That needs a new managedredis.ReservationUnitPrice. The cache recommendation producer becomes a no-op, and GetRecommendationsForService(ServiceCache) returns empty (the fix(azure): the recommendations aggregator never calls managedredis, search or synapse #47 precedent). A guard test fails if any returned recommendation is labelled ServiceCache.
Platform hazard. Platform stores Azure Redis plans and settings under cache. After a pin bump past this change, those plans match no recommendation and silently buy nothing. The platform pin bump has to ship with a companion platform change.
Owner question: in the platform, should Azure memorydb (managedredis) fold into the existing "Cache for Redis" slot, with stored cache plans mapped onto it (the default), or appear as a separate service that operators must re-configure?
The go-side tasks (C1-C4) start now. None of them is blocked.
Activity
cristim commentedon Nov 5, 2026
Claimed by claude-cc-libs: planning (read-only) how Azure Redis recommendations get labelled and routed to managedredis (ServiceMemoryDB) instead of the cache client that now refuses, covering aggregate collection, Advisor mapping and pricing. Two review passes on the plan before any code. Builds run under the current load throttle.
cristim commentedon Nov 5, 2026
Plan done (claude-cc-libs, reviewed in two passes). A premise correction, a merge-order constraint, and one owner question.
cache.PurchaseCommitmentdoesn't refuse Redis on main yet. That's fix(azure/cache): refuse Redis purchases so only managedredis buys them #694 (fix(azure): align divergent PurchaseCommitment guards and display names across services #538 item d), still open. Today, cache-labelled Azure Redis recommendations are still bought.rediscachemapping and Advisor pricing. That needs a newmanagedredis.ReservationUnitPrice. The cache recommendation producer becomes a no-op, andGetRecommendationsForService(ServiceCache)returns empty (the fix(azure): the recommendations aggregator never calls managedredis, search or synapse #47 precedent). A guard test fails if any returned recommendation is labelledServiceCache.cache. After a pin bump past this change, those plans match no recommendation and silently buy nothing. The platform pin bump has to ship with a companion platform change.Owner question: in the platform, should Azure
memorydb(managedredis) fold into the existing "Cache for Redis" slot, with storedcacheplans mapped onto it (the default), or appear as a separate service that operators must re-configure?The go-side tasks (C1-C4) start now. None of them is blocked.
fix(azure): set CacheDetails on managedredis recommendations (#692)
docs(changelog): correct the Azure Redis routing entry (#692)
fix(azure): tag held Redis reservations with the redis engine (#692)
fix(azure): give Advisor Redis recommendations the redis engine (#692)
fix(azure): make managedredis the only Azure Redis recommendation pro…
Merge origin/main into fix/538-redis-single-owner