fix(admin-cli): cap paged chunk size to the server's max_find_by_ids#2874
Merged
Conversation
The admin-cli's paged `get_all_*` wrappers chunk ids by the CLI's `page_size`, but the server's `*ByIds` RPCs reject any request whose id count exceeds `runtime_config.max_find_by_ids`. Since the two limits are configured independently, a deployment with `page_size` above the server cap would fail every paged list command with `InvalidArgument`. This routes all the wrappers through one cap, so a page never exceeds what the server accepts. - A new `ApiClient::effective_chunk_size` reads `max_find_by_ids` from the `RuntimeConfig` the `version` RPC already exposes and returns `min(page_size, cap)`; a zero/unset cap falls back to `page_size`, since chunking by zero would panic. - All 21 paged `.chunks(page_size)` sites (machines, instances, racks, switches, power-shelves, segments, VPCs, DPAs, partitions, keysets, NSGs, explored hosts/devices, ...) now chunk by the capped size. - The cap arithmetic is a pure `cap_chunk_size` helper with a unit test. Surfaced by CodeRabbit on PR NVIDIA#2833. Tests added! This supports NVIDIA#2872 Signed-off-by: Chet Nichols III <chetn@nvidia.com>
Contributor
Author
|
@coderabbitai full_review please, thanks! |
Contributor
Summary by CodeRabbit
WalkthroughApiClient now reads the server ChangesServer-cap-aware pagination
Sequence Diagram(s)sequenceDiagram
participant ApiClient
participant API_server
participant get_all_remediations
ApiClient->>API_server: version(true)
API_server-->>ApiClient: runtime_config.max_find_by_ids
ApiClient->>get_all_remediations: chunk IDs with effective_chunk_size(page_size)
get_all_remediations-->>ApiClient: accumulated results
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related issues
Possibly related PRs
🚥 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 unit tests (beta)
Comment |
Contributor
|
🐇 ✅ Action performedFull review finished. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
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 `@crates/admin-cli/src/rpc.rs`:
- Around line 107-115: The central chunk-size path in effective_chunk_size
currently allows a zero page_size to flow through cap_chunk_size, which can
later panic when used with .chunks(...). Update effective_chunk_size in rpc.rs
to reject page_size == 0 up front (or normalize it to a minimum of 1) before
applying the cap from version(true) and runtime_config.max_find_by_ids, so all
callers of this helper are guaranteed a safe nonzero chunk size.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: f905e79a-7a08-45bb-a8ca-4a087753cb77
📒 Files selected for processing (1)
crates/admin-cli/src/rpc.rs
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (2)
crates/admin-cli/src/rpc.rs (2)
2428-2443: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick winKeep remediation page fetches buffered.
This chain uses
.then(...), so remediation chunks are fetched serially, unlike the surrounding paged helpers that use.buffered(PAGED_LIST_FETCH_CONCURRENCY). Switching tomap(...).buffered(...).try_fold(...)preserves the established concurrency for large result sets.🤖 Prompt for 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. In `@crates/admin-cli/src/rpc.rs` around lines 2428 - 2443, The remediation paging logic in the `remediations` stream is fetching chunks serially because it uses `then(...)` inside the `stream::iter` chain. Update the `remediations` pipeline to match the other paged helpers by using `map(...)` followed by `.buffered(PAGED_LIST_FETCH_CONCURRENCY)` before `try_fold(...)`, while keeping the existing `find_remediations_by_ids` error mapping to `CarbideCliError::ApiInvocationError`. This preserves buffered concurrent fetches for large result sets.
2580-2590: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winMake this helper test table-driven.
This pure input/output helper already has multiple cases; use a small case table so future cap edge cases can be added without duplicating assertion structure.
Suggested refactor
#[test] fn cap_chunk_size_respects_server_limit() { - // A zero/unset cap means no server limit -- use page_size as-is. - assert_eq!(cap_chunk_size(100, 0), 100); - // A smaller cap wins, so a page never exceeds what the *ByIds RPCs accept. - assert_eq!(cap_chunk_size(100, 40), 40); - // A larger cap leaves page_size untouched. - assert_eq!(cap_chunk_size(100, 500), 100); - // Equal is a no-op. - assert_eq!(cap_chunk_size(100, 100), 100); + let cases = [ + ("zero_or_unset_cap", 100, 0, 100), + ("smaller_cap_wins", 100, 40, 40), + ("larger_cap_leaves_page_size", 100, 500, 100), + ("equal_cap_is_noop", 100, 100, 100), + ]; + + for (name, page_size, cap, expected) in cases { + assert_eq!(cap_chunk_size(page_size, cap), expected, "{name}"); + } }As per coding guidelines, "Use table-driven test style when writing tests in Rust."
🤖 Prompt for 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. In `@crates/admin-cli/src/rpc.rs` around lines 2580 - 2590, Refactor the cap_chunk_size_respects_server_limit test into a table-driven style so each input/output case is expressed as a row instead of repeated assertions. Keep the same coverage for cap_chunk_size by moving the current zero, smaller, larger, and equal cap scenarios into a small cases table and iterating over it with one assertion block, making it easy to add more edge cases later.Source: Coding guidelines
🤖 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.
Nitpick comments:
In `@crates/admin-cli/src/rpc.rs`:
- Around line 2428-2443: The remediation paging logic in the `remediations`
stream is fetching chunks serially because it uses `then(...)` inside the
`stream::iter` chain. Update the `remediations` pipeline to match the other
paged helpers by using `map(...)` followed by
`.buffered(PAGED_LIST_FETCH_CONCURRENCY)` before `try_fold(...)`, while keeping
the existing `find_remediations_by_ids` error mapping to
`CarbideCliError::ApiInvocationError`. This preserves buffered concurrent
fetches for large result sets.
- Around line 2580-2590: Refactor the cap_chunk_size_respects_server_limit test
into a table-driven style so each input/output case is expressed as a row
instead of repeated assertions. Keep the same coverage for cap_chunk_size by
moving the current zero, smaller, larger, and equal cap scenarios into a small
cases table and iterating over it with one assertion block, making it easy to
add more edge cases later.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 3b51039b-64db-42b4-bba1-4e60882a42c4
📒 Files selected for processing (1)
crates/admin-cli/src/rpc.rs
🔍 Container Scan Summary
Per-CVE detail lives in the per-service |
rwthompsonii
approved these changes
Jun 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The admin-cli's paged
get_all_*wrappers chunk ids by the CLI'spage_size, but the server's*ByIdsRPCs reject any request whose id count exceedsruntime_config.max_find_by_ids. Since the two limits are configured independently, a deployment withpage_sizeabove the server cap would fail every paged list command withInvalidArgument. This routes all the wrappers through one cap, so a page never exceeds what the server accepts.ApiClient::effective_chunk_sizereadsmax_find_by_idsfrom theRuntimeConfigtheversionRPC already exposes and returnsmin(page_size, cap); a zero/unset cap falls back topage_size, since chunking by zero would panic..chunks(page_size)sites (machines, instances, racks, switches, power-shelves, segments, VPCs, DPAs, partitions, keysets, NSGs, explored hosts/devices, ...) now chunk by the capped size.cap_chunk_sizehelper with a unit test.Surfaced by CodeRabbit on PR #2833.
Tests added!
This supports #2872