fix(azure): error instead of truncating silently at the pricing page cap

[cristim]

What

Closes #1963.

pricing.FetchAll walked the Azure Retail Prices API, stopped at its page cap, and returned the pages collected so far with a nil error, so every caller read a truncated price list as a complete one. The self-referential-link guard nine lines above already returned an explicit error for its failure mode; the cap did not. It now does.

This is a latent-defect fix, and the PR should say so

No filter the code issues reaches page two of the API today, and GetOfferingDetails, which every affected call site sits under, has no in-repo production caller. So no user-facing behaviour changes. What changes is that hitting the cap becomes an error instead of a silent truncation, which matters the moment either of those facts stops being true.

The cap stays at 50, and the comment was wrong

The constant's comment claimed the API pages at 100 items. Measured live on 2026-09-08 against api-version 2023-01-01-preview, it pages at roughly 1,000, so the cap is about 50,000 items rather than 5,000.

Query the code issues	Pages	Items
Cosmos DB, region-wide, eastus	1	112
Azure Search, region-wide	1	32
Compute, SKU-scoped	1	9
Whole VM catalogue for one region (no client issues this)	16	15,483
Global Cosmos DB	7	6,577

Nothing the code issues reaches page two, and the widest plausible shape is 16 pages against a 50-page cap. The cap stays as the runaway-chain defence it was meant to be, the comment is corrected, and the fix is the error alone rather than a number pulled from nowhere.

Verification

The regression test scripts a paginated response that still carries a page link when the cap is reached. It fails on the base commit with An error is expected but got nil and passes after, under -race.

TestFetchAll_ExactlyMaxPagesSucceeds is a positive control, not evidence of the fix: a chain filling exactly the cap with no further link must still succeed, and it passes both before and after. It scripts a 3-page chain against a cap of 3, so it exercises the boundary itself rather than a page short of it.

An independent reviewer ran six mutants of the fix and every one was killed, including an off-by-one on the page count, an inverted condition, a check against the wrong variable, and returning the partial slice alongside the error.

Check	Result
go test -count=1 -race ./... in providers/azure	all 12 packages ok
go vet ./..., gofmt -l	clean
gocyclo -over 10 on the touched file	clean (FetchAll 6 to 7)
go build ./... from the root	exit 0

No live reproduction is possible, since no real query reaches the cap. The scripted-server unit test is the scenario.

Scope

Four service-client doc comments described the cap as a silent stop and are corrected. Those hunks are comment-only. Nothing else is touched.

Noted while reviewing, not fixed here

providers/azure/services/managedredis/client.go:355-357 falls through to upfrontCost = totalCost on an unknown payment option, where the other six clients fail loud. Pre-existing and out of scope for this PR; filed separately.

Summary by CodeRabbit

• Bug Fixes

  • Azure pricing retrieval now reports an error when the pagination limit is reached before all pricing results are fetched, preventing incomplete data from being returned silently.
  • Retrieval succeeds when all available pages are completed within the configured limit.
  • Error details identify the page limit and amount of data processed.

• Documentation

  • Updated Azure pricing documentation to clarify pagination behavior, page-size expectations, and error handling.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 0cd41a88-bad2-4c58-8844-6dad32f4aae6

📥 Commits

Reviewing files that changed from the base of the PR and between 8e44c0f and 02a230b.

📒 Files selected for processing (6)

• providers/azure/internal/pricing/retail_prices.go
• providers/azure/internal/pricing/retail_prices_test.go
• providers/azure/services/cache/client.go
• providers/azure/services/compute/client.go
• providers/azure/services/cosmosdb/client.go
• providers/azure/services/database/client.go

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

Azure pricing pagination now returns an error instead of silently returning truncated results when DefaultMaxPages is reached with a pending NextPageLink. Tests cover over-cap and exact-cap chains. Service comments document the shared behavior.

Changes

Azure pricing pagination

Layer / File(s)	Summary
Cap error contract and implementation providers/azure/internal/pricing/retail_prices.go, providers/azure/services/*/client.go	FetchAll returns an error when the page cap is reached while NextPageLink remains. Comments document the error behavior and updated page-size estimates.
Cap boundary validation providers/azure/internal/pricing/retail_prices_test.go	Tests verify that over-cap chains return an error and nil results after the capped number of requests. Exactly capped chains succeed with all items.

Priority: ➖ Normal — Impact reflects medium issue severity.

Estimated code review effort: 2 (Simple) | ~10 minutes

Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to 02a23

Azure pricing retrieval now reports incomplete results at the pagination cap rather than silently using truncated data, while complete results exactly at the cap continue to succeed. The boundary behavior is covered and no current merge-blocking risk remains.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly states the primary change: Azure pricing now returns an error instead of silently truncating at the page cap.
Linked Issues check	✅ Passed	The changes satisfy issue #1963. FetchAll now errors when the page cap is reached with a remaining NextPageLink, while preserving the cap and validating both error and exact-boundary behavior.
Out of Scope Changes check	✅ Passed	The production change, regression tests, and related documentation updates are directly related to issue #1963. No unrelated code changes are present.
Docstring Coverage	✅ Passed	Docstring coverage is 83.33% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 6 functions across 6 files.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/1963-azure-pricing-truncation

---

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