Repository navigation
fix(azure): decide whether the Azure SQL dedupe key keeps the zone-redundancy slot #715
Description
Problem
After #705, Azure SQL Database held reservations carry Deployment = cachedDominantAZConfig(), the same source the SQL recommendations use (providers/azure/services/database/client.go). The duplicate guard keys on resourceType|region|engine|deployment (pkg/recfilter/dedupe.go), and for SQL the deployment slot is DatabaseDetails.AZConfig (pkg/common/deployment.go).
There are two cases where the keys still differ, and in both the guard fails open:
- The server and managed-instance walk fails while the recommendations are built (AZConfig ""), then succeeds after the retry delay when held reservations are read ("zoneRedundant"/"none").
- The fleet's zone-redundancy shape changes between the client that produced the recommendations and a fresh client that reads held reservations (the MCP dedupe builds one client per service/region group).
Proposal
Decide whether the Azure SQL dedupe key should drop the deployment slot, with a provider/service branch next to dedupeEngine in pkg/recfilter/dedupe.go. This first needs the Azure fact of whether an Azure SQL Database vCore reservation applies to both zone-redundant and non-zone-redundant compute. If it does, the slot only splits one pool into two keys. If it does not, the slot must stay and the two cases above need another fix.
Follow-up to #705.
Activity
cristim commentedon Nov 7, 2026
Update from #717: within one client, held SQL reservations now reuse the zone-redundancy value the recommendation path stamped (
recordRecommendationAZConfig), so a failed recommendation lookup followed by a successful inventory walk keys both sides the same. Residual cases that still fail open and that this issue covers:GetExistingCommitmentsruns on a client before any recommendation was converted (no caller uses this order today).Dropping the deployment slot from the Azure SQL key would close all three, and it can only over-filter (fail safe for spend).
cristim commentedon Nov 10, 2026
Claimed by claude-ui-fix-1 (fleet). The Azure fact this issue asked for is settled by Microsoft's docs (https://learn.microsoft.com/en-us/azure/azure-sql/database/reserved-capacity-overview): a
vCorereservation covers standard compute, zone-redundant or not; zone redundancy is a separate reservation type only for the General Purpose zone-redundancy add-on (vCore ZR), and the purchase attributes (subscription, scope, region, deployment type, performance tier, type, term, quantity) have no zone-redundancy dimension on standard compute. So the deployment slot (zoneRedundant/none, stamped from the fleet's dominant shape, not from the reservation itself) only splits one pool into two keys. Plan: drop the slot from the Azure SQL dedupe key with a provider/service branch next to dedupeEngine in pkg/recfilter/dedupe.go, test-first. It can only over-filter (a held vCore ZR add-on reservation would count in the pool), which fails safe for spend. Two cold staged-diff review passes, then one PR.