Skip to content

Conversation

@rektdeckard
Copy link
Member

@rektdeckard rektdeckard commented Sep 30, 2025

https://linear.app/livekit/issue/CUS-276/livekit-cli-add-support-for-pagination-to-lk-sip-outboundinbound-list

Creates an ExhaustivePaginatedList helper function for chunking large data sets using repeated paginated List* SDK requests to skirt Twirp's 4MB payload limit. Implements it for sip inbound list and sip outbound list.

We should also apply this to other potentially large data sets for room, dispatch, ingress and egress list operations.

Worth noting: the SIP SDK does not seem to respect the Limit yet, but this change should be transparent and will resolve when SDKs are updated.

@rektdeckard rektdeckard requested a review from dennwc September 30, 2025 00:26
@rektdeckard rektdeckard force-pushed the tobias/cus-276-livekit-cli-add-support-for-pagination-to-lk-sip branch from 725d85e to c1c431b Compare September 30, 2025 00:41

type paginatedType[T any] interface {
protoType[T]
GetPage() *livekit.Pagination
Copy link
Contributor

Choose a reason for hiding this comment

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

We plan to use this for phone numbers
https://github.com/livekit/protocol/blob/main/protobufs/livekit_models.proto#L31
Should we account for this as well ?

Copy link
Member Author

Choose a reason for hiding this comment

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

Sure, I'll take a look

}
}
return nil
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to worry about local memory if the api returns a large amount say thousands of phone numbers ?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't know any modern machine that couldn't handle a few MB or even tens of MB or allocation, and this is a short-lived object. I would suggest we impose limit if and only if we get issues? This worked fine with 22K trunks in testing.

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.

3 participants