Repository navigation
fix(azure): align divergent PurchaseCommitment guards and display names across services #538
Description
Found while planning #9 (ARCH-02). The 7 Azure PurchaseCommitment bodies (providers/azure/services/<svc>/client.go) diverge in ways that look like bugs. Each is a behavior change, so it is kept out of the #9 refactor:
- (a) Only synapse rejects a blank
ResourceType(synapse:303). The other six sendsku.name: ""to Azure. - (b) synapse's count-guard message drops the count (synapse:308). The other six say "...got %d".
- (c) managedredis (:330) and synapse (:339) use a fixed, unsanitized
displayNamewith no region, term or timestamp. The other five useBuildDisplayName. - (d) cache (:348) and managedredis (:325) both purchase
RedisCache. See fix(azure): the recommendations aggregator never calls managedredis, search or synapse #47 and #1508 for which service owns Azure Redis. - (e) compute wraps a term-parse error as "failed to marshal request: %w" (compute:509), and checks the payment option before the term.
Proposed fix: once the #9 shared helper lands, align (a) to (c) and (e) on the majority behavior, each with a test. Settle (d) with the Redis-ownership decision.
Activity
cristim commentedon Oct 20, 2026
Two more items, found while writing the #9 golden tests:
capacityProviderOnce(compute) is spent even when the first call is cancelled, and the list-then-purchase window is not atomic. [claude-cc-libs]cristim commentedon Oct 20, 2026
Claiming items (a), (b), (c), (e) and (f): align the divergent guards, messages, display names and compute's error order on the majority behavior, now that all 7 services share the #9 helper. Item (d), Redis ownership, is an owner decision, and item (g), the pre-existing races, needs its own design; both are listed for the owner. [claude-cc-libs]
test(azure): pin the Source, ResourceType, Count guard order
fix(azure): align PurchaseCommitment guards, messages and display nam…
cristim commentedon Oct 20, 2026
#550 (merged) fixes items (a), (b), (c), (e) and (f). Item (d), Redis ownership, and item (g), the pre-existing compute and list-then-purchase races, stay open for the owner. [claude-cc-libs]
cristim commentedon Nov 5, 2026
Owner decision (2026-11-05): Option A. managedredis owns Redis purchases; the cache service stops purchasing Redis, with a guard against double-buying. Next: remove Redis purchasing from cache and add the guard.
cristim commentedon Nov 5, 2026
Claimed by claude-nibblets: implementing item (d) per the owner decision (Option A). managedredis stays the only service that purchases Azure Redis; the cache service stops purchasing Redis and refuses before any API call, with a guard against double-buying. Working in a worktree off origin/main, test first; PR to follow.
test(azure/cache): refuse a ServiceCache-labelled Redis recommendation
Merge origin/main into fix/538-redis-single-owner
fix(azure/cache): refuse Redis purchases so only managedredis buys th…
cristim commentedon Nov 11, 2026
Closing as fixed on main. Items (a), (b), (c), (e) and (f) landed in #550, and item (d) (Redis ownership, Option A) landed in #694: the cache client refuses PurchaseCommitment and managedredis is the only Redis purchaser. The remaining item (g), the compute capacity-provider race and the list-then-purchase window, is filed separately: #745