Support for large RPC messages using data streams by 1egoman · Pull Request #1013 · livekit/rust-sdks

1egoman · 2026-04-13T20:03:43Z

This is port of the identically named client-sdk-js pull request livekit/client-sdk-js#1832, adding support for RPC protocol version 2, via feeding the spec to a LLM.

Warning

This pull request was LLM generated and has only been lightly reviewed by a human. The author has tested this and confirms it works in the happy path, but no other validation has been done.

A more thorough review of this needs to occur before it could be merged. The plan is to hand this off to a rust sdk maintainer to get it fully across the line.

github-actions · 2026-04-13T20:03:55Z

Changeset

The following package versions will be affected by this PR:

Package	Bump
`livekit`	`patch`
`livekit-api`	`patch`
`livekit-ffi`	`patch`

1egoman · 2026-04-13T20:07:18Z

+// =========================================================================
+// v2 -> v2 tests (both sides support data streams)
+// =========================================================================
+
+/// Spec #1: Caller happy path (short payload) — v2 data stream used.
+#[tokio::test]
+async fn test_v2_v2_caller_happy_path_short() {
+    let client = Arc::new(RpcClientManager::new());
+    let transport = Arc::new(
+        MockTransport::new()
+            .with_remote_protocol("dest", CLIENT_PROTOCOL_DATA_STREAM_RPC),
+    );
+
+    let handle = spawn_perform_rpc(
+        client.clone(),
+        transport.clone(),


Note to any reviewers: The tests here don't use the larger e2e test infrastructure in this repository purposely, because some test need to fully emulate the behavior of an old client (ie, doing things like always sending RpcRequest / RpcResponse even with a newer client_protocol, etc).

I am not sure if this is a good idea or not. Halfway through the process, the LLM basically said it couldn't generate the tests with the e2e infrastructure and proposed this as an alternative so I let it go for it.

There's also been some divergence for the single peer connection tests; in a follow-up, we should ensure all the E2EE tests are using common testing utilities (and make sure they can support any configuration needed by the test), but I would say for now it's better to include the tests even if they use different infrastructure.

xianshijing-lk · 2026-04-22T04:47:12Z

+    /// Override the client_protocol advertised during join. If `None`, falls back
+    /// to `CLIENT_PROTOCOL_DEFAULT` (0). The SDK's default constructor sets this
+    /// to `CLIENT_PROTOCOL_DATA_STREAM_RPC` (1) to advertise data-stream RPC support.
+    pub client_protocol: Option<i32>,


Nit
why not just make it a i32 and default to 0 , rather than optional

Looking at this again, I don't really understand why this even has to be a struct member. I think it should match the js implementation and just be a constant called something like ADVERTISED_CLIENT_PROTOCOL. Updated to use this constant approach instead in 4e63807.

xianshijing-lk · 2026-04-22T04:53:43Z

+                &data.payload,
+                effective_timeout,
+            )
+            .await


do we need .map_err(|e| { for v2 ?

I don't think this is needed - send_v2_request's returned error type is RpcError, and perform_rpc (the function this is in) returns Result<String, RpcError>.

xianshijing-lk · 2026-04-22T04:58:36Z

+
+// RPC protocol version constants (distinct from client_protocol; this is the
+// version field on RpcRequest / v2 stream attributes).
+pub(crate) const RPC_VERSION_V1: u32 = 1;


nit, use bool ?

This should be able to able to be incremented beyond two values, so I think keeping it some kind of uint makes sense.

ladvoc · 2026-04-22T08:55:01Z

+        Self { handlers: Mutex::new(HashMap::new()) }
+    }
+
+    pub fn register_method(


suggestion: I have a WIP PR (#858) to allow RPC method registration prior to room connection. I haven't merged this yet since the FFI portion is incomplete and requires some larger architectural changes, but the core change in the livekit crate is finished and could potentially be integrated here.

Nice! There's enough conflicts on that linked pull request where I think it probably makes more sense to integrate these as part of inevitably fixing the merge conflicts when that pull request is rebased.

ladvoc · 2026-04-22T08:59:04Z

+// =========================================================================
+// v2 -> v2 tests (both sides support data streams)
+// =========================================================================
+
+/// Spec #1: Caller happy path (short payload) — v2 data stream used.
+#[tokio::test]
+async fn test_v2_v2_caller_happy_path_short() {
+    let client = Arc::new(RpcClientManager::new());
+    let transport = Arc::new(
+        MockTransport::new()
+            .with_remote_protocol("dest", CLIENT_PROTOCOL_DATA_STREAM_RPC),
+    );
+
+    let handle = spawn_perform_rpc(
+        client.clone(),
+        transport.clone(),


There's also been some divergence for the single peer connection tests; in a follow-up, we should ensure all the E2EE tests are using common testing utilities (and make sure they can support any configuration needed by the test), but I would say for now it's better to include the tests even if they use different infrastructure.

reenboog · 2026-04-23T17:22:22Z

Postponing my review until 1832.

…:default()

It doesn't need to be drilled through as an option, it's fundamentally tied to the broader code context it is part of.

xianshijing-lk · 2026-04-24T20:22:49Z

I think the code in general looks clean and easy to follow for me. what is the plan of landing it ?

This should match PROTOCOL_VERSION.

1egoman · 2026-04-24T20:33:46Z

@reenboog FWIW, the plan was to merge this and livekit/client-sdk-js#1832 at the same time - I don't want to get into the situation where the web version gets merged and this one gets blocked for a while and then it's a web only feature. Also, holding off on merging the web one means we can make protocol updates to v2 which are non backwards compatible during the review, if required. So, feel free to take a look at this now.

This is easier to follow and matches better with how the v2 version works

…anager as methods

1egoman · 2026-04-27T17:22:53Z

In regards to all the ci failures - this looks to be a github problem, NOT a problem with this branch. See here for another example of this arduino/setup-protoc@a8b67ba40b37d35169e222f3bb352603327985b6 action being unable to be downloaded: #1049

I'll rerun these in a few hours and hopefully this is transient / that will fix it.

xianshijing-lk

lgtm

1egoman commented Apr 13, 2026

View reviewed changes

1egoman requested review from ladvoc and reenboog April 13, 2026 20:14

1egoman mentioned this pull request Apr 21, 2026

Support for large RPC messages using data streams livekit/client-sdk-js#1832

Open

4 tasks

xianshijing-lk reviewed Apr 22, 2026

View reviewed changes

ladvoc reviewed Apr 22, 2026

View reviewed changes

1egoman added 8 commits April 24, 2026 15:50

feat: implement client protocol support in rust sdk

332e837

feat: add new rpc v2 functionality (RpcClientManager / RpcServerManager)

74a8fcc

feat: add rpc tests for v1 / v2 rpc protocol types

a53e78a

feat: rename files and abstract magic numbers into constants

2546920

fix: move client protocol definitions to livekit-api

d7879c2

fix: ensure CLIENT_PROTOCOL_DATA_STREAM_RPC is set in RoomSdkOptions:…

1713fd1

…:default()

fix: add missing license header

d97de53

Create wip_support_for_large_rpc_messages_using_data_streams.md

3980b10

1egoman force-pushed the rpc-with-data-streams branch from d37f3ae to 3980b10 Compare April 24, 2026 19:55

1egoman added 2 commits April 24, 2026 16:05

fix: address incorrect license header years

7fc7b17

refactor: move advertised client protocol into constant

4e63807

It doesn't need to be drilled through as an option, it's fundamentally tied to the broader code context it is part of.

1egoman added 2 commits April 24, 2026 16:26

fix: run cargo fmt

702ca0c

refactor: rename ADVERTISED_CLIENT_PROTOCOL -> CLIENT_PROTOCOL_VERSION

29fe346

This should match PROTOCOL_VERSION.

refactor: switch from if block -> .then

85c55e7

1egoman marked this pull request as ready for review April 24, 2026 20:46

1egoman changed the title ~~(WIP) Support for large RPC messages using data streams~~ Support for large RPC messages using data streams Apr 24, 2026

1egoman added 4 commits April 24, 2026 16:56

refactor: make handle_request take HandleRequestOptions

cc75a94

fix: run cargo fmt

c82affe

fix: move publish_rpc_request into self.send_v1_request method

e98ab99

This is easier to follow and matches better with how the v2 version works

refactor: move publish_rpc_response / publish_rpc_ack into RpcServerM…

f1c4081

…anager as methods

fix: run cargo fmt

a16a4e6

xianshijing-lk removed the request for review from reenboog April 30, 2026 17:50

xianshijing-lk approved these changes Apr 30, 2026

View reviewed changes

Conversation

1egoman commented Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changeset

Uh oh!

1egoman Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

1egoman Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

1egoman Apr 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

reenboog commented Apr 23, 2026

Uh oh!

xianshijing-lk commented Apr 24, 2026

Uh oh!

1egoman commented Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

1egoman commented Apr 27, 2026

Uh oh!

xianshijing-lk left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

1egoman commented Apr 13, 2026 •

edited

Loading

github-actions Bot commented Apr 13, 2026 •

edited

Loading

1egoman Apr 13, 2026 •

edited

Loading

1egoman Apr 24, 2026 •

edited

Loading

1egoman Apr 22, 2026 •

edited

Loading

1egoman commented Apr 24, 2026 •

edited

Loading