Repository navigation
fix(azure/gcp/aws): ctx.Err guards + page cap on 22 pagination loops (closes #691) - #800
Conversation
…loses #691) Add ctx.Err() early-return guards and maxPages budget caps to all unbounded pagination loops across Azure (14 loops), GCP (6 loops), and AWS (2 loops). Context cancellation now terminates loops immediately with a wrapped error instead of either continuing or silently returning a partial result set, matching the pattern from PR #690 and the feedback_ctx_cancel_terminal rule. Fixes in collect* helpers (cache, cosmosdb) and the inline search loop that previously used ctx.Err()+break (silently partial) -- changed to return the error so callers propagate it. Also fixes two nil-context test calls in cache/client_test.go that panicked after the ctx.Err() guard was introduced. Regression tests added: Azure cache GetValidResourceTypes ctx-cancel + page cap, GCP computeengine GetRecommendations ctx-cancel + page cap, AWS fetchCoveragePaged ctx-cancel.
|
@coderabbitai review |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughAdds context-cancellation checks and explicit pagination caps to recommendation and resource-enumeration loops across AWS, Azure, and GCP providers, converting unbounded pager/iterator loops into index-based iterations that abort on canceled contexts or when configured page caps are exceeded. ChangesPagination Safety Hardening Across Cloud Providers
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@providers/gcp/services/computeengine/client.go`:
- Around line 656-662: GetValidResourceTypes currently treats
maxMachineTypesPages as a page cap while MachineTypesIterator.Next() yields one
machine type per call, so fix the semantics by switching to an item-based cap:
rename or replace maxMachineTypesPages with maxMachineTypes (or
maxMachineTypeItems), use a descriptive counter like itemIdx (instead of
pageIdx) to count Next() iterations, and update the error message in the check
inside GetValidResourceTypes to reflect an item cap (e.g., "computeengine:
GetValidResourceTypes iteration cap (%d items) reached") so the constant name
and message match the actual behavior of MachineTypesIterator.Next().
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 3ccf2039-ca1e-4d31-a971-fc5a876bce06
📒 Files selected for processing (13)
providers/aws/recommendations/coverage.goproviders/aws/recommendations/coverage_test.goproviders/aws/recommendations/utilization.goproviders/azure/services/cache/client.goproviders/azure/services/cache/client_test.goproviders/azure/services/compute/client.goproviders/azure/services/cosmosdb/client.goproviders/azure/services/database/client.goproviders/azure/services/search/client.goproviders/gcp/services/cloudsql/client.goproviders/gcp/services/computeengine/client.goproviders/gcp/services/computeengine/client_test.goproviders/gcp/services/memorystore/client.go
MachineTypesIterator.Next() yields one machine type per call, not one page. Rename maxMachineTypesPages -> maxMachineTypeItems and pageIdx -> itemIdx so the names and error message match the actual iteration semantics.
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
The ctx.Err pagination guards added in this PR pushed two functions just over the project's gocyclo > 10 ceiling, failing pre-commit: - providers/azure/services/search/client.go GetValidResourceTypes (12) - providers/aws/recommendations/utilization.go GetRIUtilization (11) Each is split into a thin entry point plus a focused helper: - GetValidResourceTypes -> resolveServicesPager + collectSKUsFromPager - GetRIUtilization -> buildUtilizations for the agg-to-slice tail Behaviour unchanged; 323 tests pass across the two packages.
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
Summary
ctx.Err()early-return guards at the top of every pagination loop (Azurefor pager.More(), GCPfor { it.Next() }, AWSfor { token }) so a cancelled or deadline-expired context terminates immediately with an error instead of silently producing a partial result set.maxPagesbudget cap per loop with a log warning or returned error when the limit is hit, preventing infinite loops against stalled or unexpectedly deep AWS/Azure/GCP APIs.collect*helper functions in Azure cache and cosmosdb that previously returnedmap[string]boolwithout an error channel, causing context cancellations to silently produce partial SKU sets. Signatures changed to(map[string]bool, error)and callers updated.Total: 14 Azure loops + 6 GCP loops + 2 AWS loops = 22 loops covered.
Test plan
go build ./...clean inproviders/azure,providers/gcp,providers/awsgo test ./...green in all three provider modules (85+ tests passing)GetValidResourceTypesctx-cancel returns error (not partial result)GetValidResourceTypespage cap terminates and falls back to common SKUsGetRecommendationsctx-cancel returns errorGetRecommendationspage cap returns errorfetchCoveragePagedctx-cancel returns errorSummary by CodeRabbit
Bug Fixes
Tests