bug: piped ListApplications silently truncates paginated results

---

name: Bug Report
about: Report a bug encountered
labels: kind/bug

---

What happened:
PipedAPI.ListApplications only returns the first datastore page for a piped's applications. When applicationStore.List returns a non-empty cursor, the RPC ignores it and returns immediately, so applications beyond the first page are silently dropped.

Summary

pkg/app/server/grpcapi/piped_api.go fetches a single page from applicationStore.List and discards the returned cursor. A piped that manages more applications than fit in one datastore page receives an incomplete application list.

Affected Area

• pkg/app/server/grpcapi/piped_api.go
• callers of pipedservice.PipedService/ListApplications

What you expected to happen:
ListApplications should return a complete application set for the piped. With the current RPC contract, that means iterating datastore pages internally until the cursor is exhausted before returning the response.

Expected Behaviour

ListApplications collects all pages from applicationStore.List and returns the full application list without requiring client-side pagination support.

How to reproduce it:

1. Mock applicationStore.List for PipedAPI.ListApplications so the first call returns one application plus a non-empty cursor.
2. Make the second call return another application and an empty cursor.
3. Invoke PipedAPI.ListApplications.
4. Observe on current master that only the first application is returned because the second page is never fetched.

Steps to Reproduce

1. Seed or mock a project/piped with more applications than the datastore returns in one page.
2. Call PipedAPI.ListApplications.
3. Observe that only the first page is returned and no continuation cursor is exposed to the piped client.

Environment:

• piped version: current master as of July 21, 2026
• control-plane version: current master as of July 21, 2026
• Others: Not applicable

Actual Behaviour

Only the first datastore page is returned, and remaining applications are silently omitted.

Technical Evidence

• pkg/app/server/grpcapi/piped_api.go contains TODO: Support pagination in ListApplications immediately before apps, _, err := a.applicationStore.List(ctx, opts).
• The method ignores the returned cursor and responds with that single page.
• The public API path already supports pagination separately, so this bug is isolated to the piped gRPC path rather than the general application listing API.

Suspected Root Cause

PipedAPI.ListApplications does not loop on datastore.ListOptions.Cursor and has no way to return a continuation cursor in the existing response type.

Proposed Direction

Keep the current RPC contract and paginate internally in PipedAPI.ListApplications until the datastore cursor is empty, with a focused unit test that proves multi-page results are fully aggregated.

Acceptance Criteria

• A mocked multi-page applicationStore.List test for PipedAPI.ListApplications returns all applications across pages.
• A piped with more than one datastore page of applications receives a complete list.
• Existing single-page callers continue to behave the same.

Start in pkg/app/server/grpcapi/piped_api.go at the TODO before applicationStore.List. Trace the existing ListApplications flow and its datastore cursor handling, then add a focused unit test using the two mocked pages described in the issue. Done means the RPC returns applications from every page, while single-page callers retain their current behavior.