Bump livekit ffi to 0.12.73 - #766
Open
1egoman wants to merge 5 commits into
Open
Conversation
…on based data streams implementation still exists
1egoman
force-pushed
the
bump-livekit-ffi
branch
2 times, most recently
from
July 28, 2026 21:28
5c0d922 to
758f0f1
Compare
Regenerated with the toolchain the CI job uses (protoc 25.1 + mypy-protobuf 3.6.0), picking up the new data track schema messages (DefineSchema / GetSchema). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`uvx ruff` resolves to the newest ruff release on every run, so the 0.16.0 release turned CI red on main and on open PRs without any code change: its expanded default rule set reports 700+ findings and its formatter now rewrites code blocks in markdown. Using `uv run ruff` pins the linter to the version in uv.lock (0.15.4), so lint results only move when the lockfile is intentionally updated. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1egoman
commented
Jul 29, 2026
Comment on lines
20
to
-25
|
|
||
| # Use the ruff version pinned in uv.lock rather than uvx's latest release, | ||
| # so lint results only change when the lockfile is intentionally updated. | ||
| - name: Ruff livekit-api | ||
| run: uvx ruff check --output-format=github . | ||
| run: uv run ruff check --output-format=github . | ||
|
|
||
| - name: Check format | ||
| run: uvx ruff format --check . |
Contributor
Author
There was a problem hiding this comment.
This is a bit of a drive by fix, but I noticed that running ruff otherwise locally resulted in different formatted code then what I was getting in CI (which left the ci build in a failing state)
1egoman
marked this pull request as ready for review
July 29, 2026 16:31
1egoman
requested review from
cloudwebrtc,
lukasIO and
xianshijing-lk
as code owners
July 29, 2026 16:31
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
Contributor
Author
|
Did a final round of light testing with a data streams v2 capable client:
I did some ac hoc conversation back and forth and the whole agent lifecycle seemed to work fine. I could use some help validating anything more in depth though that uses data streams, like any specific plugins / etc. |
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
1 participant
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.
Updates
livekit-ffito the latest version, which contains data streams v2.In addition to the ffi package update itself, there's a bit more that has to be done here because the python sdk today has its own data streams implementation. I'm working on migrating this package to use the
livekit-ffiprovided data streams but in the meantime, if thelivekit-ffiupdate was done today, then it would mean that the newly introducedclient_protocolof2would be advertised, and the pre-existing python implementation would receive data stream v2 messages, not v1 (ie, single packet data streams, compression, etc could be sent to the existing python data streams code).To address this, I've added a temporary livekit-ffi specific
options.data_stream.use_legacy_client_implementationflag which can be set to disable advertising the new client protocol. What this means in practice:client_protocolof1, so no inline content / compression)livekit-ffi's data streams implementation, just like it works today)Once
livekit-ffidata stream migration is done in the above linked pull request, I'll merge it and drop this flag both here and on the rust sdk end, and then everything will use data streams v2 everywhere.I've tested this locally (all the data streams and rpc paths above) with success.
Todo
livekit-ffirelease