ListEvents can exceed page size after label filtering

What happened:

WebAPI.ListEvents applies label filtering after fetching datastore pages, then keeps appending matching events while scanning additional pages until it has at least PageSize matches. If the final scanned page contains multiple matching events after the threshold is crossed, the response can exceed the requested logical page size. The handler then returns the datastore cursor from the final scanned page, which makes filtered pagination unstable for event timelines.

Summary

ListEvents can return an oversized filtered response when label matches are spread across multiple datastore pages.

Affected Area

pkg/app/server/grpcapi/web_api.go, specifically WebAPI.ListEvents and its label-filtered pagination path.

What you expected to happen:

ListEvents should return one logical filtered page, no larger than the requested PageSize, and provide a cursor suitable for continuing to the next filtered page without duplicates or dropped events.

Expected Behaviour

The API should enforce a stable logical page size after label filtering and return a cursor for the next filtered page.

How to reproduce it:

1. Seed or mock multiple datastore pages of events with label matches spread across pages.
2. Call WebAPI.ListEvents with Options.Labels and a PageSize smaller than the total matching events.
3. Make the first page contain fewer matching events than PageSize, and a later fetched page contain enough matches to cross the threshold by more than one event.
4. Observe that the response includes more than PageSize events because every matching event from the final scanned page is appended.

Actual Behaviour

The endpoint can return an uncapped list of matched events encountered during the scan, exceeding the requested page size.

Technical Evidence

ListEvents builds datastore ListOptions with Limit: pageSize, fetches one page, filters by labels in memory, then repeats while len(filtered) < pageSize. Inside the repeat loop, every matching event from the newly fetched datastore page is appended. There is currently a TODO noting the overflow risk immediately before returning the response:

• pkg/app/server/grpcapi/web_api.go: // TODO: Think about possibility that the response of ListEvents exceeds the page size

This mirrors the same post-filter pagination risk that exists in ListDeployments.

Suspected Root Cause

Label filtering happens after datastore pagination, but the filtered slice is never capped back to the requested logical page size before the response is returned. The returned cursor is the datastore cursor from the final scanned page.

Proposed Direction

Refactor the filtered pagination path so ListEvents only returns up to PageSize filtered events. If possible, share the helper with the equivalent ListDeployments path so both handlers use consistent cursor semantics.

Acceptance Criteria

• ListEvents enforces a stable logical page size after label filtering.
• Cursor-based continuation yields no duplicate or dropped events.
• Tests cover dense matches, sparse matches, and zero-match scenarios.

Environment:

• piped version: Not applicable; this is a control-plane WebAPI handler issue.
• control-plane version: Current upstream master as of 2026-07-24.
• Others: Not applicable.

Start in pkg/app/server/grpcapi/web_api.go at WebAPI.ListEvents and its label-filtered pagination loop, then compare the equivalent ListDeployments path. Add or update tests for dense, sparse, and zero-match label results, and verify that responses respect PageSize while cursor continuation has no duplicates or dropped events.