Skip to content

feat(public): read every page of the Public API's lists - #1098

Merged
Topherhindman merged 4 commits into
mainfrom
topherhindman/devx-879-lists-read-items-and-follow-cursors
Nov 3, 2026
Merged

Topherhindman merged 4 commits into
mainfrom
topherhindman/devx-879-lists-read-items-and-follow-cursors

Conversation

@Topherhindman

Copy link
Copy Markdown
Contributor

Part of DEVX-879

Why

The Public API changes the shape of every list. Each list response is now items plus pageInfo, and takes page.cursor and page.pageSize. The keys, webhooks and webhook events lists no longer return keys, webhooks and events. A session's logs, traces and metrics no longer return records, spans and points. Project and workspace members, invites and API keys are now paged. The scoped keys list is gone; the keys list takes an ownerId instead. Cursors are opaque.

lk 2.19.2 reads the old fields. Against the new API it shows empty lists, or only the first page of members, invites and keys. This PR must ship in the lk release that goes out with the API change.

What changed

  • The client is regenerated from the new spec. The list wrappers read items.
  • Member, invite, key and webhook lists follow pageInfo.nextCursor until the last page, and return every row. A repeated cursor fails instead of looping.
  • lk project key list --mine asks the API who the signed-in user is, then lists keys with ownerId. Its output is unchanged.
  • The project and workspace caches read every page. Before, they held only the first page, so --project and --workspace could not name a project or workspace past it.
  • lk workspace list, lk workspace project list and lk user list still show one page at a time with --limit and --cursor.

Testing

  • go build ./... and go vet ./... pass on every commit.
  • go test ./... passes at the head, except 7 TestScripts cases (rejected-session, no-session, session-only-in-legacy-mode, not-yet-under-user-auth, expired-session, no-default-project, default-project). They fail the same way on main when a coding agent is installed, because of the skills tip line. test(lk): script tests turn off the skills prompt #1088 fixes that.
  • New scripts key-list-pages, key-list-mine and project-list-pages check that lk follows cursors to the last page and that --mine sends ownerId. key-commands-as-admin and the member-removal-* scripts pass.
  • Unit tests cover the paging loop: it stops at the last page and fails on a repeated cursor.
  • On 2026-10-30, all 35 lk commands that use the Public API were run against a local API server with the new list shape, and they followed its cursors. The final spec changes only doc comments in the generated client, so lk's code is the same as in that run.

@rektdeckard rektdeckard left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we ready to deploy public-api as it currently is (with the list change) to prod? If so, bump version.go and we should do that tonight so we don't get caught off-guard by the need to deploy a bugfix or smth.

@Topherhindman

Copy link
Copy Markdown
Contributor Author

Are we ready to deploy public-api as it currently is (with the list change) to prod? If so, bump version.go and we should do that tonight so we don't get caught off-guard by the need to deploy a bugfix or smth.

yeah we can

Picks up the Public API's list changes. Every list response is now
{items, pageInfo}: the keys, webhooks and webhook events lists drop
keys, webhooks and events, and a session's logs, traces and metrics
drop records, spans and points. Project and workspace members and
invites, and API keys, are now paged, so their client methods take
page parameters. ListScopedKeys is gone; ListKeys takes an ownerId
instead.

The regenerated client doesn't build against the old wrappers, so this
commit carries the changes it forces. The wrappers read items and pass
no page parameters yet, so the newly paged lists return their first
page. ListKeys takes a KeyFilter with the owner, and lk project key
list --mine asks the Public API who the signed-in user is and lists the
keys that user owns, where it used to take the personal half of
ListScopedKeys. Its output is unchanged.

Also picks up the builder agent endpoints the client gained since
livekit/public-api-server@7bfa9ec, which no command uses yet.

Generated from livekit/public-api-server@bdeef2a
The Public API now pages project and workspace members and invites, and
a project's API keys, 100 to a page by default. lk shows these lists
whole, so ListProjectMembers, ListProjectInvites, ListWorkspaceMembers,
ListWorkspaceInvites and ListKeys pass each page's nextCursor back
until the API says there are no more, and return every row.

ListWebhooks and ListWebhookEvents do the same. The API answers them in
one page today, so they make one request as before, but a list it pages
later still comes back whole.

allPages holds the loop. It stops at a page whose pageInfo says it is
the last, and fails rather than reading forever if a cursor repeats.
cmd/lk's readPages doesn't fit: it reads up to a user's --limit and
hands back the cursor where it stopped, for commands that page at the
user's request.
lk caches the signed-in user's projects and workspaces so --project and
--workspace resolve names offline, and lk project list prints the
project cache. ListProjects read only the first 100 projects, and the
workspace cache held only the first 200 workspaces, so a user with more
couldn't name the rest.

ListProjects and the new ListAllWorkspaces now read every page with
allPages. lk workspace list, lk workspace project list and lk user list
keep their one page at a time, since they take --limit and --cursor.
@Topherhindman
Topherhindman force-pushed the topherhindman/devx-879-lists-read-items-and-follow-cursors branch from 1266058 to c420a23 Compare November 3, 2026 00:55
@Topherhindman
Topherhindman merged commit da97ed1 into main Nov 3, 2026
26 checks passed
@Topherhindman
Topherhindman deleted the topherhindman/devx-879-lists-read-items-and-follow-cursors branch November 3, 2026 02:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants