Current behavior
The app/CF Events tabs are a point-in-time paginated fetch, not a live stream. The frontend loader (src/frontend/packages/core/src/shared/services/data-sources/cnsi-entity-source.ts, ~lines 122-162) fetches page 1 (per_page=100), reads totalPages, then drains all remaining pages (4-way concurrency) into an in-memory array which is then client-paginated. There is no cap in the current code.
Meanwhile the comments tell a different story:
CnsiAuditEventsSource header: "drains pagination up to maxAuditEventPages (50 pages × 500 events = 25k events)"cloud-foundry-events-list.component.ts:22: "The handler caps at 25k events."
Those describe the previous backend handler, which full-drained up to 25k events and then stopped collecting. That handler was rewritten to a plain per_page/page passthrough precisely because the full drain breached memory (src/jetstream/plugins/cloudfoundry/native_audit_events_reads.go:22-24) — but the rewrite moved the unbounded drain to the browser instead of eliminating it.
Problem
On a foundation with a large audit-event history, opening the Events tab makes the frontend fetch the entire history. The memory blow-up the backend rewrite was avoiding now happens client-side, plus the stale comments actively mislead readers about a safety cap that no longer exists.
Proposed direction
- Fetch a bounded newest-first window instead of draining: CAPI supports
order_by=-created_at, so the tab can load the most recent N pages and page further on demand.
- Fix the stale 25k comments to describe whatever behavior is actually implemented.
Found while researching whether events collection behaves as a circular buffer (it is neither circular nor capped — it is an unbounded historical drain, refreshed only on manual Refresh).
Current behavior
The app/CF Events tabs are a point-in-time paginated fetch, not a live stream. The frontend loader (
src/frontend/packages/core/src/shared/services/data-sources/cnsi-entity-source.ts, ~lines 122-162) fetches page 1 (per_page=100), readstotalPages, then drains all remaining pages (4-way concurrency) into an in-memory array which is then client-paginated. There is no cap in the current code.Meanwhile the comments tell a different story:
CnsiAuditEventsSourceheader: "drains pagination up to maxAuditEventPages (50 pages × 500 events = 25k events)"cloud-foundry-events-list.component.ts:22: "The handler caps at 25k events."Those describe the previous backend handler, which full-drained up to 25k events and then stopped collecting. That handler was rewritten to a plain per_page/page passthrough precisely because the full drain breached memory (
src/jetstream/plugins/cloudfoundry/native_audit_events_reads.go:22-24) — but the rewrite moved the unbounded drain to the browser instead of eliminating it.Problem
On a foundation with a large audit-event history, opening the Events tab makes the frontend fetch the entire history. The memory blow-up the backend rewrite was avoiding now happens client-side, plus the stale comments actively mislead readers about a safety cap that no longer exists.
Proposed direction
order_by=-created_at, so the tab can load the most recent N pages and page further on demand.Found while researching whether events collection behaves as a circular buffer (it is neither circular nor capped — it is an unbounded historical drain, refreshed only on manual Refresh).