Repository navigation
Register the SDK's own transport with livekit-net - #1106
Merged
Merged
Conversation
pblazej
force-pushed
the
blaze/rust-net-adapter
branch
4 times, most recently
from
September 2, 2026 14:46
22d5249 to
cf00102
Compare
Contributor
Author
|
Blocked by UniFFI release (soon) 🚫 works locally tho |
pblazej
marked this pull request as ready for review
September 2, 2026 14:50
pblazej
requested review from
hiroshihorie and
xianshijing-lk
as code owners
September 2, 2026 14:51
1egoman
approved these changes
Sep 14, 2026
1egoman
left a comment
1egoman
left a comment
Contributor
There was a problem hiding this comment.
Generally makes sense to me from a 10k foot view level, but I'm unable to effectively review the lower level swift idiosyncrasies
Contributor
Author
|
@1egoman are you going to change the rust side? It's not a high-priority to me (no consumers atm) |
Contributor
No rust changes are planned to this interface AFAIK at the moment, unless you are planning some 😄 |
xianshijing-lk
approved these changes
Sep 15, 2026
livekit-net leaves the WebSocket and HTTP clients to the host. Rather than add a second, parallel URLSession stack for the Rust side, adapt the one already here, so Rust-side signalling inherits the tuning the Swift path gets: .callSignaling QoS, multipath handover, extended background idle, the iOS 26 simulator TLS workaround, and the delegate's error logging. Registration is a lazy global, forced from ConnectionDependencies.init: process-wide rather than connection-scoped, since livekit-net keeps the first registration, but that is the earliest construction on the connect path, so no signalling can outrun it and a Room that never connects pays nothing. WebSocket gains a headers/timeout init (SignalClient supplies its own Authorization header) and keeps the HTTP status off a rejected upgrade, which is what livekit-net's TransportError::Http carries: livekit-signaling maps it to SignalError::Handshake, where a 404 gates the v1 -> v0 signalling path fallback and other statuses fail fast rather than driving a reconnect loop. HTTP.request now owns the cache policy and timeout as parameters, so the shared session's URLCache can't serve a stale validate or region response to either caller. The tests drive the seam from Rust through the FFI using livekit-net's own self_test_* exports, so nothing is asserted against a mock. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The released bindings name the setter argument `c`, not `client`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
pblazej
force-pushed
the
blaze/rust-net-adapter
branch
from
September 22, 2026 13:53
1ab7cd0 to
7e7b64f
Compare
The UniFFI enum is non-frozen, so a switch over it needs `@unknown default` once the module is built with library evolution enabled. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: omnigent <noreply@omnigent.ai>
HttpMethod is non-frozen, so a newer LiveKitFFI binary can add a case, for example PUT. The adapter sent such a request as GET, which is a valid request with different semantics. makeRequest now throws TransportError.Other for an unknown case, and request(method:url:...) returns that error to livekit-net. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: omnigent <noreply@omnigent.ai>
WsClientAdapter.connect turned livekit-net's header list into a dictionary, so entries with the same name collapsed to the last value, for example two Sec-WebSocket-Protocol entries. WebSocket now takes an ordered list of name/value pairs and adds each one with addValue, so every entry reaches the request. SignalClient passes its single Authorization header in the same form. The request is built in WebSocket.makeRequest, which a unit test drives with repeated names that also differ only in case. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: omnigent <noreply@omnigent.ai>
RustTransportTests contacted the server without the shared readiness gate that withRooms and the Objective-C helper use, so a slow simulator start could fail them. The suite init now calls TestEnvironment.waitForServer, which is public for this. The init comment now names ConnectionDependencies.init, which is where the SDK forces the transport registration. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: omnigent <noreply@omnigent.ai>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
livekit-netdoes not include its own WebSocket and HTTP clients. The host app must supply them. This PR giveslivekit-netthe existingWebSocketandHTTPstack of the SDK, through an adapter of about 180 lines. The SDK does not get a secondURLSessionimplementation.The Rust side uses the same session as the Swift side, so it gets the same behavior. That includes the
.callSignalingQoS, multipath handover, and the TLS workaround for the iOS 26 simulator.Changes:
Sources/LiveKit/Support/Network/RustTransport.swift. It callssetWsClient(c:)andsetHttpClient(c:)from LiveKitFFI one time, on first access.ConnectionDependencies.inittriggers it, before any signaling starts.livekit-netgives for a WebSocket upgrade. If a header name repeats, the request keeps all of its values.livekit-netreturns this status asTransportError::Http, andlivekit-signalingmaps it toSignalError::Handshake. A 404 status starts the fallback from the v1 path to the v0 path.HttpMethodcase that this SDK does not know withTransportError.Other. Before this change, the adapter sent such a request as GET.The
RustTransportTestssuite goes from Rust back through the FFI. It uses theself_test_*exports oflivekit-netagainst a livelivekit-server. No test uses a mock.Local results on macOS, with
livekit-server1.13.7 started aslivekit-server --devandenable_participant_data_blob: true:swift test --no-parallel --filter RustTransportTests: all 14 tests (24 test cases) passed.swift test --no-parallel --filter LiveKitCoreTests: 580 of 588 tests passed, 0 failed, and 8 skipped. The skipped tests are inCooperativePoolBlockingTests, which skips them by design.swiftlintandswiftformat --lintfound no issues in the changed files.This PR uses the LiveKitFFI 0.13.1 pin from main and does not change a package file. LiveKitFFI 0.13.1 contains the
livekit-netbindings inlivekit_net.swift. The earlier blocker, livekit/rust-sdks#1362, merged on 2026-09-08.