Add support for RPC V2 - #1087
Conversation
|
Caution Breaking change detected without major changeset
If this is intentional, please add a changeset with |
|
^ In the above "breaking change" warning, it looks like the issue is: But it's a field addition... That shouldn't be a breaking change? Let me know what I am missing - I could I think make this private, but I'd need to verify that is ok first. |
| E2EContainer? container; | ||
| late Room room; | ||
|
|
||
| group('rpc tests', () { | ||
| test('test rpc handler register', () async { | ||
| container = E2EContainer(); | ||
| room = container!.room; | ||
| await container!.connectRoom(); | ||
|
|
||
| room.registerRpcMethod('echo', (RpcInvocationData data) async { |
There was a problem hiding this comment.
question: Heads up that I kept all the old / pre-existing rpc v1 tests around. I'm not sure though if this is really still needed, because the new tests should be testing all the same paths. I'll defer to what others think here, I don't have a strong opinion on if they should be kept or removed.
This can be used to exercise sending / receiving rpc requests in the example app
…n livekit/protocol)
Add ClientProtocolVersion, and adds this to connectOptions. Just like the swift version, thie can be configured on connection for testing purposes.
xianshijing-lk
left a comment
There was a problem hiding this comment.
some nits / questions
| /// `ParticipantInfo.clientProtocol`. Drives the caller- and handler-side decision | ||
| /// between RPC v1 packets and RPC v2 data streams. Absent / unrecognized values | ||
| /// from older clients resolve to `0` (matches [ClientProtocolVersion.v0]). | ||
| int get clientProtocol => _participantInfo?.clientProtocol ?? ClientProtocolVersion.v0.toIntValue(); |
There was a problem hiding this comment.
Just want to make sure I understand, this _participantInfo is the remote participant info, right ?
| throw RpcError(code: RpcError.sendFailed, message: 'No local participant'); | ||
| } | ||
|
|
||
| final writer = await local.streamText(StreamTextOptions( |
There was a problem hiding this comment.
can you tell me where this streamText() is implemented ? local_participant.dart ?
Attach the RPC test controller to the active room instead of passing a room through each handler registration. Clear stale handlers when the sheet moves to another room, avoid registering against disposed rooms, and let handler card text use the theme's default text colors.
# Conflicts: # lib/src/participant/local.dart
Add caller-side RPC v2 coverage for legacy v1 fallback, pre-publish payload rejection, fast ack/response handling, and malformed response streams without request IDs.
Brings 18 upstream commits, notably 42f6b14 "fix: allow selectAudioOutput on Android" (livekit#1121) — without it Hardware.selectAudioOutput early-returned with "only supported on Desktop", so the in-call output picker was inert on Android. selectAudioOutput now refuses only on Web/iOS. Conflict resolution: - lib/src/options.dart — both sides added a RoomOptions field in the same place. Kept both: our pendingTrackQueueMaxSize and upstream's networkOptions. - lib/src/core/room.dart — kept our prefixed pending_queue.PendingTrackQueue construction (metadataTimeout, not upstream's ttl) and added upstream's RpcClientManager/RpcServerManager init from the RPC v2 work (livekit#1087). Dropped the VP9 patch (cffd8a7 "vp9 experiment"): web/e2ee.frame_cryptor.dart is restored to upstream. That patch made getUnencryptedBytes return 0 for VP9 — encrypt the whole frame, header included — while every other peer (native libwebrtc, the JS SDK) uses the standard key=10 / delta=3 prefix. Since the same function runs on both encrypt and decrypt, the mismatch means a VP9 frame from mobile cannot be decrypted on web and vice versa, and with failureTolerance: -1 it fails silently rather than surfacing an error. It is also redundant: upstream fixed VP9 E2EE properly in b835995 (livekit#953), which narrowed the frame-cryptor skip from isSVCCodec to isAV1Codec, and that fix is already in this branch. Our patch predates it by a month and targeted the same symptom via the wrong mechanism. Verified: flutter analyze clean, all 70 tests in test/core pass, and the three patches the fork exists for are intact (pending_track_queue rejoin hardening, pendingTrackQueueMaxSize, iOS podspec 16.0).
The RPC tester itself landed on main through #1087, which included a hardened copy of this branch's rpc_test_sheet.dart and the controls.dart wiring. Resolve the add/add conflict by taking main's version, so this branch now carries only follow-up fixes.
See this pull request for more info about what this does and how rpc v2 works: livekit/client-sdk-js#1832
Also, for an in depth description of behavior in edge cases, see RPC_SPEC.md here.
Warning
This pull request was LLM generated and has only been lightly reviewed by the author, who is not a flutter expert. I have tested this and can confirm 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.