Conversation
pblazej
force-pushed
the
blaze/rust-net-adapter
branch
3 times, most recently
from
September 2, 2026 14:33
0f413f8 to
22d5249
Compare
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>
pblazej
force-pushed
the
blaze/rust-net-adapter
branch
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
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
| var request = URLRequest(url: url) | ||
| request.httpMethod = switch method { | ||
| case .get: "GET" | ||
| case .post: "POST" |
Contributor
There was a problem hiding this comment.
curiously, do we need to support other https methods ? like PUT, PATCH, DELETE ?
Contributor
Author
There was a problem hiding this comment.
There are 0 rust consumers at the moment (1st would be telemetry), so this is more like speculation based on full rust feature set, we can double check and maybe update the interface.
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
3 participants
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-netleaves the WebSocket and HTTP clients to the host, so this wraps the SDK's existingWebSocket/HTTPstack in ~180 lines of adapter rather than adding a second, parallelURLSessionimplementation — the Rust side inherits.callSignalingQoS, multipath handover and the iOS 26 simulator TLS workaround for free.WebSocketalso keeps the HTTP status off a rejected upgrade, whichlivekit-netcarries asTransportError::Httpandlivekit-signalingmaps toSignalError::Handshake, where a 404 gates the v1 → v0 path fallback.The tests drive the seam from Rust back through the FFI using
livekit-net's ownself_test_*exports against a livelivekit-server, so nothing is asserted against a mock.Draft: needs
livekit-uniffi0.1.10 — 0.1.9 has no transport seam, so CI can't build this until that release lands (blocked on livekit/rust-sdks#1362).