Summary
GetOfferingDetails in the Azure Managed Redis client falls through to upfrontCost = totalCost when it meets a payment option it does not recognise. The other six Azure service clients fail loud on the same input. An unknown payment option therefore produces a plausible-looking upfront figure derived from the wrong basis, rather than an error, and nothing downstream can tell the difference.
This is the silent-fallback pattern the project forbids on money paths: the honest outcome for an unrecognised enum value is an error, not a substituted default.
Location
providers/azure/services/managedredis/client.go:355-357
Failure scenario
The Retail Prices API returns a reservation term or payment option this client has no case for, for instance a new Azure payment model or a renamed meter. The default arm assigns the full total cost as the upfront cost. A caller reads an offering whose upfront figure describes a payment structure the customer did not choose, with no error and no log line marking it as a guess.
Evidence
default:
upfrontCost = totalCostCompare the sibling clients, which return an error for an unrecognised option rather than substituting one.
Suggested fix
Return an error naming the unrecognised payment option, matching the six sibling clients. That keeps the seven Azure clients consistent and removes the only place where an unknown enum silently produces a money figure.
Provenance
Found during adversarial review of LeanerCloud/cloud-commitments-cli#2074 (the pricing page-cap fix), in code adjacent to the change but not touched by it. Deliberately left out of that PR to keep it scoped.
Latent today: GetOfferingDetails has no in-repo production caller, so nothing currently reaches this branch. That lowers its priority but not its correctness, and #11 tracks the decision about whether that surface is revived or deleted. If it is revived, this should be fixed first.
Summary
GetOfferingDetailsin the Azure Managed Redis client falls through toupfrontCost = totalCostwhen it meets a payment option it does not recognise. The other six Azure service clients fail loud on the same input. An unknown payment option therefore produces a plausible-looking upfront figure derived from the wrong basis, rather than an error, and nothing downstream can tell the difference.This is the silent-fallback pattern the project forbids on money paths: the honest outcome for an unrecognised enum value is an error, not a substituted default.
Location
providers/azure/services/managedredis/client.go:355-357Failure scenario
The Retail Prices API returns a reservation term or payment option this client has no case for, for instance a new Azure payment model or a renamed meter. The
defaultarm assigns the full total cost as the upfront cost. A caller reads an offering whose upfront figure describes a payment structure the customer did not choose, with no error and no log line marking it as a guess.Evidence
default: upfrontCost = totalCostCompare the sibling clients, which return an error for an unrecognised option rather than substituting one.
Suggested fix
Return an error naming the unrecognised payment option, matching the six sibling clients. That keeps the seven Azure clients consistent and removes the only place where an unknown enum silently produces a money figure.
Provenance
Found during adversarial review of LeanerCloud/cloud-commitments-cli#2074 (the pricing page-cap fix), in code adjacent to the change but not touched by it. Deliberately left out of that PR to keep it scoped.
Latent today:
GetOfferingDetailshas no in-repo production caller, so nothing currently reaches this branch. That lowers its priority but not its correctness, and #11 tracks the decision about whether that surface is revived or deleted. If it is revived, this should be fixed first.