fix(azure): carry the source reservation's applied scope through an RI exchange

[cristim]

What

An Azure RI exchange no longer buys the replacement reservation with AppliedScopeType = Shared by default. The source reservation's applied scope is carried from the tenant listing through CalculateExchange into every reservationsToPurchase entry.

• ExchangeableReservation gains AppliedScopeType (armreservations.AppliedScopeType) and AppliedScopes, populated by ListExchangeableReservations from Properties.AppliedScopeType / Properties.AppliedScopes.
• CalculateExchange refuses, before calling Azure:
  • a source with no reported scope (applied_scope_type is required; pass the reservation as returned by ListExchangeableReservations)
  • a scope type outside the SDK enum (for example ManagementGroup, which this SDK/API version cannot express on a purchase)
  • Single without exactly one applied scope (Azure's MissingAppliedScopesForSingle / InvalidSingleAppliedScopesCount)
  • every refusal wraps the exported sentinel compute.ErrUnsupportedAppliedScope (%w), so callers can match it with errors.Is
  • sources whose scopes differ (type, or for Single the scope set, compared case-insensitively and order-free; scopes on Shared sources are ignored), because one purchase cannot keep two scopes
• buildCalculateExchangeRequest sends sources[0]'s scope type on every target, and its single scope only when the type is Single (appliedScopes stays nil, so it is omitted from the JSON, for Shared). The hard-coded AppliedScopeTypeShared fallback is gone.
• ExchangeTarget.AppliedScopeType is removed. It could not express the subscription list a Single scope needs, and its nil value was the Shared fallback. Nothing in this repo or the platform sets it (checked cloud-commitments-platform at HEAD: internal/api/handler_ri_exchange.go:661 builds ExchangeTarget without it).

Why

Exchanging a reservation Single-scoped to prod for chargeback returned a Shared reservation, so other subscriptions took the discount and prod paid on-demand, and nothing in the request or response said so (#57).

Azure contract (api-version 2022-03-01, the version armreservations v1.1.0 calls: calculateexchange_client.go:98)

• Calculate Exchange, PurchaseRequest: properties.appliedScopeType (Single | Shared) and properties.appliedScopes, "List of the subscriptions that the benefit will be applied. Do not specify if AppliedScopeType is Shared." No default is documented. https://learn.microsoft.com/en-us/rest/api/reserved-vm-instances/calculate-exchange/post?view=rest-reserved-vm-instances-2022-03-01
• Reservation List All, ReservationsProperties: appliedScopeType, appliedScopes, plus appliedScopeProperties (management group / tenant), which the v1.1.0 SDK does not model. https://learn.microsoft.com/en-us/rest/api/reserved-vm-instances/reservation/list-all?view=rest-reserved-vm-instances-2022-03-01
• SDK (armreservations@v1.1.0): PurchaseRequestProperties.AppliedScopeType/AppliedScopes at models.go:652-657, Properties.AppliedScopeType/AppliedScopes at models.go:548-553, enum AppliedScopeTypeShared/AppliedScopeTypeSingle at constants.go:21-22.

What the platform must change to benefit

toAzureExchangeSources (internal/api/handler_ri_exchange.go:639) builds sources from the request body with only ReservationID and Quantity. After bumping this module, every Azure exchange will be refused with ErrUnsupportedAppliedScope (sources[0]: unsupported applied scope: applied_scope_type is required) until the handler passes the matching entry from the owned listing it already fetches for requireAzureSourceOwnership, with the request's quantity, and map ErrUnsupportedAppliedScope to a 4xx (today mapAzureExchangeError turns anything that is not an *azcore.ResponseError 4xx into a generic 500). That refusal is intentional: the alternative is the silent Shared purchase. Hence Refs #57, not Closes: the end-to-end fix needs that platform change.

How verified

GOTOOLCHAIN=go1.26.6 GOWORK=off GOFLAGS='-p=2 -count=1' AWS_EC2_METADATA_DISABLED=true, in providers/azure:

• go build ./..., go vet ./..., go test ./...: all pass. go test -race ./services/compute/: 251 passed.
• golangci-lint run ./services/compute/...: no issues. gofmt -l: clean.
• No other module imports providers/azure/services/compute.

Failing before: with the new tests and the new ExchangeableReservation fields but exchange_operations.go from origin/main:

--- FAIL: TestCalculateExchange_ValidationSources (0.00s)
    "azure: CalculateExchange returned no session id" does not contain "sources[0]: applied_scope_type is required"
    ...
--- FAIL: TestCalculateExchange_PreservesSingleScopeOfSources (0.00s)
    expected: "Single"
    actual  : "Shared"
    expected: []*string{(*string)(0x1cb1aa183180)}
    actual  : []*string(nil)
FAIL

Passing after: ok github.com/LeanerCloud/cloud-commitments-go/providers/azure/services/compute.

Mutation: disabling the same-scope check (if false && !s.sameAppliedScope(...)) fails ValidationSources/shared_mixed_with_single and ValidationSources/single_on_different_subscriptions. Reverted.

This is fixture-based evidence: no real Azure exchange was priced or executed.

Reviewer should challenge

• Whether refusing mixed-scope sources is right, compared with letting the caller choose a scope per target. That is option 2 in fix(azure): RI exchange silently forces AppliedScopeType to Shared, reallocating the discount #57 and is not built here.
• A Shared source that Azure reports with stray appliedScopes has them dropped: nothing is sent for Shared, per the contract.
• Removing the exported ExchangeTarget.AppliedScopeType field breaks the API for any consumer outside LeanerCloud.

Update: review fixes. appliedScopes is no longer sent as [] for Shared (asserted nil and absent from the marshalled JSON), refusals wrap ErrUnsupportedAppliedScope, Single requires exactly one scope, and scope lists are compared only for Single.

[coderabbitai]

Warning

Review limit reached

• Run on-demand review

_{This review includes 4 billable files and costs up to $1.00.}

• Ask an admin to make reviews automatic

Open in CodeRabbit

Reviews can continue after your included limit without a manual trigger. An admin must approve usage-based billing.

Or wait 7 minutes for your next included review.

Check out review usage here.

View limit details

Limit details: You’ve used all 2 included reviews currently available. Your 50 included PR review attempts over the past 7 days set your current allowance at 2 reviews per hour.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Repository: LeanerCloud/cloud-commitments-go/.coderabbit.yaml
• Review profile: CHILL
• Plan: Essentials
• Run ID: 94cebd33-e011-48f2-9eef-eab1a5678c72

📥 Commits

Reviewing files that changed from the base of the PR and between 40427f6 and 0ac2dff.

📒 Files selected for processing (4)

• providers/azure/services/compute/exchange.go
• providers/azure/services/compute/exchange_operations.go
• providers/azure/services/compute/exchange_operations_test.go
• providers/azure/services/compute/exchange_test.go

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

_{Comment @coderabbitai help to get the list of available commands.}