fix(azure): cap and cancel-check the eight remaining pager loops - #246
Conversation
Eight pager loops in cache, cosmosdb, database, managedredis, synapse and compute/exchange had no page cap and no ctx.Err() check, unlike their siblings. A cancelled context or an endless pager now stops the walk: loops that return errors report the cap or the context error; the log-and-degrade loops (SKU catalogue, Cosmos API type, SQL server and managed-instance walks) log and return their existing failure value. Closes #93
|
@coderabbitai full review |
|
Warning Review limit reached
This review includes 12 billable files and costs up to $3.00.
Reviews can continue after your included limit without a manual trigger. An admin must approve usage-based billing. Or wait 13 minutes for your next included review. View limit detailsLimit details: You’ve used the included review currently available. Your 61 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. Review configuration: ⚙️ Run configuration
📒 Files selected for processing (12)
Comment |
|
Extract the per-page bodies of fetchSKUCatalogue, synapse GetRecommendations and walkManagedInstances so each stays at or below 10.
hasRegularServers now returns (found, complete); fetchServerInfo blanks AZConfig and Deployment when the server walk was cut short by the page cap, cancellation or a page error. Also extracts tallyManagedInstances to keep walkManagedInstances under the cyclomatic limit.
Assert exactly cap pages succeed and cap+1 fails at cap calls, and add cancel-mid-walk cases for compute exchange and managedredis.
What
Adds the page cap and
ctx.Err()check the sibling loops already use to the eight pager loops listed in #93:cachefetchSKUCatalogue(capmaxCachesPages)cosmosdbfetchDominantAPIType(capmaxAccountsPages)databasewalkManagedInstancesandhasRegularServers(newmaxSQLListPages = 20)managedredisGetExistingCommitments(newmaxReservationsPages = 50)synapseGetRecommendationsandcollectSynapseReservations(newmaxRecsPages,maxReservationsPages)computecollectExchangeableReservations(existingmaxReservationsPages)Behaviour change
walkManagedInstancesreturnscomplete=false, as in fix(azure): leave AZConfig and Deployment empty on a managed-instance page error #240.How verified
Fake pagers report More() for 1000 pages. Each loop has a cap test (calls stop at the cap) and a cancelled-context test (zero NextPage calls). Normal multi-page behaviour stays covered by the existing tests. Pre-fix the compute tests fail ("An error is expected but got nil", cancel error nil); removing the cap in the cosmosdb loop fails its test (expected 20, actual 1000).
go vet ./...,go test ./...andgolangci-lint run ./...pass in providers/azure (exit 0).hasRegularServersnow returns(found, complete);fetchServerInfoblanks AZConfig and Deployment when the server walk is incomplete (cap, cancel, page error), so an incomplete walk no longer reads as "no servers" and yields Deployment "managed".Follow-ups (not in this PR)
Loops with the same shape:
managedredis/client.go~427 (collectSKUsFromPager),savingsplans/client.go~155,provider.go~478 (locations),accounts_cache.go~212 (subscriptions),recommendations.go~345 (Advisor), plus the two loops in #103.serverInfoOncecaching a cancelled first fetch is pre-existing and tracked in #241.Closes #93