Streaming a kind with `bloomctl list` silently returns only the first API page, which reads as a complete result and corrupts downstream analysis. In a live session (2026-07-18) `bloomctl list vulnerability --limit 5000` returned exactly 50 records; the tenant actually holds 3,882 (13 pages at size=300 via `bloomctl api get_vulnerability_management_vulnerabilities --param page=N`). An analyst concluded the fleet had ~27 active findings when it had 1,321 active critical/high — the silent-truncation failure mode, worst case.
Likely related: `bloomctl list audit_event --since 96h` returns 0 records while `bloomctl api get_audit_events --param start_date=...` returns thousands (that endpoint is cursor-paginated via `cursor`, and `--since` may be mapped to nothing).
Expected: `list` follows each endpoint's pagination envelope (page/size, offset/limit, or cursor/next) to exhaustion, or fails loudly when it cannot.
Additive severity note: the API also silently ignores unknown pagination params — `get_vulnerability_management_detections` with `page=N` re-serves page 1 forever (observed 150,300 rows = 300 uniques x 501 calls before catching it; correct pagination is `after` cursor). A guard that warns when successive pages hash identically would catch both classes.
Streaming a kind with `bloomctl list` silently returns only the first API page, which reads as a complete result and corrupts downstream analysis. In a live session (2026-07-18) `bloomctl list vulnerability --limit 5000` returned exactly 50 records; the tenant actually holds 3,882 (13 pages at size=300 via `bloomctl api get_vulnerability_management_vulnerabilities --param page=N`). An analyst concluded the fleet had ~27 active findings when it had 1,321 active critical/high — the silent-truncation failure mode, worst case.
Likely related: `bloomctl list audit_event --since 96h` returns 0 records while `bloomctl api get_audit_events --param start_date=...` returns thousands (that endpoint is cursor-paginated via `cursor`, and `--since` may be mapped to nothing).
Expected: `list` follows each endpoint's pagination envelope (page/size, offset/limit, or cursor/next) to exhaustion, or fails loudly when it cannot.
Additive severity note: the API also silently ignores unknown pagination params — `get_vulnerability_management_detections` with `page=N` re-serves page 1 forever (observed 150,300 rows = 300 uniques x 501 calls before catching it; correct pagination is `after` cursor). A guard that warns when successive pages hash identically would catch both classes.