Upgrade to prost 0.14 across the whole project by 1egoman · Pull Request #1447 · livekit/rust-sdks

1egoman · 2026-09-21T17:50:39Z

Previously, prost 0.12 was being used in some places (ie, livekit-protocol), and 0.14 in others (ie, livekit, livekit-signaling, etc).

This made it annoying in the livekit-ffi / livekit-uniffi merge (#1438), because a single crate was now re-exporting potentially many different subcrates with differering prost versions. So this meant that the new merged livekit-ffi now had to track two different prost versions which was pretty gross.

I can't figure out a good reason why 0.12 is used in the places it is, so this pull request upgrades everything to 0.14 and pins all prost versions to the workspace version via workspace = true. I'm opting to break this out from the livekit-ffi / livekit-uniffi merge because it is sufficiently decoupled and seems like a good idea to do regardless of how that merge effort goes.

Also, upgrades pbjson-types to 0.9 since that specifies a prost 0.14 peer dependency.

Closes CLT-2441

Previously, prost 0.12 was being used in some places (livekit-protocol), and 0.14 in others (livekit, livekit-signaling, etc). This made it annoying in the livekit-ffi / livekit-uniffi merge, because a single crate was now re-exporting potentially many different subcrates, potentially with different prost versions. I can't figure out a good reason _why_ 0.12 is used in the places it is, so this pull request upgrades everything to 0.14 and pins all prost versions to the workspace version via `workspace = true`. Also, upgrades `pbjson-types` to `0.9` since that specifies a prost 0.14 peer dependency.

github-actions · 2026-09-21T17:51:09Z

Changeset ✓

This PR includes a changeset covering all affected packages:

Package	Bump
`livekit`	`patch`
`livekit-api`	`patch`
`livekit-capture`	`patch`
`livekit-common`	`patch`
`livekit-data-stream`	`patch`
`livekit-datatrack`	`patch`
`livekit-ffi`	`patch`
`livekit-protocol`	`major`
`livekit-rpc`	`patch`
`livekit-signaling`	`patch`
`livekit-token`	`patch`
`livekit-uniffi`	`patch`

Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com>

Missed one, oops

devin-ai-integration

Devin Review found 1 new potential issue.

1 flag not posted on this PR by your GitHub settings — view it in Devin Review. (Configure)

devin-ai-integration · 2026-09-21T20:01:27Z

@@ -0,0 +1,17 @@
+---
+livekit: patch
+livekit-api: patch


🟡 Patch release breaks Twirp callers

With livekit-api marked patch, TwirpClient::request changes its public prost::Message bound from 0.12 to 0.14. Existing callers using 0.12-generated messages no longer compile after a patch upgrade.

Learn more

TwirpClient is publicly re-exported from the services module, and its request methods accept caller-defined types implementing this crate's prost::Message. Traits from prost 0.12 and 0.14 are different Rust types. A caller can therefore satisfy the old bound but not the new one, even when its generated message is otherwise unchanged. Publishing that transition as a patch violates the existing API contract.

Example: An application generates CustomRequest with prost 0.12 and passes it to TwirpClient::request. Updating only livekit-api to this patch release changes the required trait to prost 0.14, so the same call stops compiling.

Recommended fix: Mark livekit-api as a breaking release in the changeset. Also audit every patched crate whose public API exposes livekit-protocol types; moving that dependency to its new major version can create the same downstream type-identity break.

Suggested change

livekit-api: patch

livekit-api: major

Was this helpful? React with 👍 or 👎 to provide feedback.

The bindings have been regenerated, but do the changes constitute any breaking API changes? Looking at the diff for the bindings, I only see formatting/syntax differences.

Yes, I agree - it's a similar issue as #1447 (comment)

ladvoc

LGTM ✅, my only outstanding question is whether it really needs a major release.

ladvoc · 2026-09-22T20:07:21Z

From our sync: since the Prost derive macros implement traits from that crate, this needs to be a minor release (marked as major in the changeset for release manager).

…vekit-protocol release (#1464) Fixes #1461. ## The bug `.changeset/upgrade_to_prost_0_14_across_the_whole_project.md` lists `livekit-uniffi: patch` **twice**. The second one was appended by a65fe9d ("fix: upgrade livekit-uniffi prost 0.12 straggler") to a list that already had it. Knope cannot parse front matter with a duplicate key — it fails the whole file: ``` Running step PrepareRelease(...) Error: changesets::could_not_read_changeset × invalid front matter ``` The Knope Bot swallows that error and regenerates the release PR from the *remaining* changesets. There is no comment and no failing check — the release PR just quietly omits every package the file was supposed to bump. Verified by dry-running knope 0.23.0 against a worktree of `main`: moving this one file out reproduces the contents of #1455 exactly, which contains no `livekit-protocol`. ## Why it shipped a broken crate The prost changeset has had no effect since #1447 merged, so `livekit-protocol` stayed at 0.7.13 (prost `^0.12`). But the prost 0.14 source was on `main`, and `livekit-data-stream` got a patch bump from an unrelated changeset (`reliable-dc-replay`) in release PR #1423. So 0.1.6 went to crates.io as: | crate | published | `prost` | `livekit-protocol` | |---|---|---|---| | livekit-protocol 0.7.13 | 2026-09-08 | `^0.12` | — | | livekit-data-stream 0.1.5 | 2026-09-09 | `^0.12` | `^0.7.13` | | **livekit-data-stream 0.1.6** | **2026-09-23** | **`^0.14`** | `^0.7.13` | Two prost versions in one graph, which is the `E0599: no method named encoded_len` in #1461. ## The fix Remove the duplicate line. `knope release --dry-run` then succeeds and produces: ``` webrtc-sys = 0.3.47, livekit-protocol = 0.8.0, livekit-api = 0.8.1, livekit-token = 0.2.1, livekit-signaling = 0.1.4, libwebrtc = 0.3.50, livekit = 0.9.3, livekit-ffi = 0.12.81, livekit-uniffi = 0.2.1, livekit-datatrack = 0.2.1, livekit-common = 0.1.4, livekit-data-stream = 0.1.7, livekit-rpc = 0.1.3, livekit-capture = 0.1.3 ``` Once this lands the bot will regenerate #1455 with `livekit-protocol` 0.8.0 included, and merging that unblocks the reporter. I checked the changeset's package list is complete for a breaking `livekit-protocol` bump: the only crates left out of that set — `livekit-net`, `livekit-region`, `livekit-token-source`, `livekit-wakeword`, `device-info` — reach neither `livekit-protocol` nor any other bumped crate. ## Follow-up (not in this PR) `.github/workflows/changeset-check.yml` already guards against knope's other silent-ignore case (quoted package names, #1411), but not duplicate keys — which is worse, since it discards the whole file rather than one line. Worth adding to `changeset_detect.py`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

@MaxHeimbrock

> [!IMPORTANT] > Merging this pull request will create these releases # livekit 0.9.3 (2026-09-24) ## Fixes - Avoid panics when malformed RTC error headers contain non-ASCII text. - Java version in libwebrtc was bumped by Google, downgrade it again for Unity 2022 build compatibility - #1456 (@MaxHeimbrock) - refactor(signaling): explicit signal lifecycle state machine - #1402 (@lukasIO) - Upgrade to prost 0.14 across the whole project - #1447 (@1egoman) # livekit-token 0.2.1 (2026-09-24) ## Fixes - Upgrade to prost 0.14 across the whole project - #1447 (@1egoman) # livekit-signaling 0.1.4 (2026-09-24) ## Fixes - refactor(signaling): explicit signal lifecycle state machine - #1402 (@lukasIO) - Upgrade to prost 0.14 across the whole project - #1447 (@1egoman) # livekit-datatrack 0.2.1 (2026-09-24) ## Fixes - Upgrade to prost 0.14 across the whole project - #1447 (@1egoman) # livekit-api 0.8.1 (2026-09-24) ## Fixes - refactor(signaling): explicit signal lifecycle state machine - #1402 (@lukasIO) - Upgrade to prost 0.14 across the whole project - #1447 (@1egoman) # libwebrtc 0.3.50 (2026-09-24) ## Fixes - Avoid panics when malformed RTC error headers contain non-ASCII text. - Java version in libwebrtc was bumped by Google, downgrade it again for Unity 2022 build compatibility - #1456 (@MaxHeimbrock) # livekit-uniffi 0.2.1 (2026-09-24) ## Fixes - Format the generated Swift bindings with swiftformat when building the Swift package. - Upgrade to prost 0.14 across the whole project - #1447 (@1egoman) # livekit-common 0.1.4 (2026-09-24) ## Fixes - Upgrade to prost 0.14 across the whole project - #1447 (@1egoman) # livekit-ffi 0.12.81 (2026-09-24) ## Fixes - Avoid panics when malformed RTC error headers contain non-ASCII text. - Java version in libwebrtc was bumped by Google, downgrade it again for Unity 2022 build compatibility - #1456 (@MaxHeimbrock) - refactor(signaling): explicit signal lifecycle state machine - #1402 (@lukasIO) - Upgrade to prost 0.14 across the whole project - #1447 (@1egoman) ### Export SoxResampler through UniFFI `SoxResampler` is now a UniFFI object, so foreign hosts can construct one and drive `push` / `flush` directly, receiving the resampled samples by value. The FFI request surface is unchanged: `NewSoxResampler`, `PushSoxResampler` and `FlushSoxResampler` still hand back a pointer into the resampler's own buffer, readable until the next call on that resampler. Both paths are covered by new tests that drive them with the same input and compare the results. # livekit-data-stream 0.1.7 (2026-09-24) ## Fixes - Upgrade to prost 0.14 across the whole project - #1447 (@1egoman) # livekit-protocol 0.8.0 (2026-09-24) ## Breaking Changes - Upgrade to prost 0.14 across the whole project - #1447 (@1egoman) # livekit-capture 0.1.3 (2026-09-24) ## Fixes - Avoid panics when malformed RTC error headers contain non-ASCII text. - Java version in libwebrtc was bumped by Google, downgrade it again for Unity 2022 build compatibility - #1456 (@MaxHeimbrock) - refactor(signaling): explicit signal lifecycle state machine - #1402 (@lukasIO) - Upgrade to prost 0.14 across the whole project - #1447 (@1egoman) # webrtc-sys 0.3.47 (2026-09-24) ## Fixes - Avoid panics when malformed RTC error headers contain non-ASCII text. - Java version in libwebrtc was bumped by Google, downgrade it again for Unity 2022 build compatibility - #1456 (@MaxHeimbrock) # livekit-rpc 0.1.3 (2026-09-24) ## Fixes - Upgrade to prost 0.14 across the whole project - #1447 (@1egoman) Co-authored-by: knope-bot[bot] <152252888+knope-bot[bot]@users.noreply.github.com>

…fi` with `room-apis` and`core-modules` modes (#1438) ## Background Ever since we [introduced livekit-uniffi](#750) at the start of 2026, it has been getting increasingly confusing what the difference between `livekit-ffi` (existing C ABI ffi solution used by python, node, unity, and c++ sdks that exposes a full rust owned webrtc stack) and `livekit-uniffi` (new uniffi powered ffi solution used by swift, android, and flutter that exposes utility modules) actually are to those that haven't been intimately involved with the rust adoption initiative. This has become even more confusing now that we have recently [added uniffi to the livekit-ffi crate](#1308)... 😬 The original intention was that `livekit-uniffi` would be a somewhat transitional "playground" we could use to experiment with uniffi and make sure we were ready to commit to it before moving everything wholesale over to it. We're now at the point where we're ready to commit to it, so this change aims to consolidate all FFI usage (both C ABI FFI and uniffi flavors) into one monolithic `livekit-ffi` crate again. ## Overview Moves all code from `livekit-uniffi` into `livekit-ffi` and **outright removes** the `livekit-uniffi` crate. This implements "phase 3" of the C ABI -> uniffi migration plan document discussed last month. `livekit-ffi` now has two top level "modes" controlled by features: - The `room-apis` mode is exactly what `livekit-ffi` used to be - the C ABI ffi stack using the `livekit` crate that manages a full webrtc stack. This build is still built in ci exactly as it was before, and consumed by python/node/unity/c++. - The `core-modules` mode ie exactly what `livekit-uniffi` used to be - the newer uniffi exposed set of utilities which are consumed by the swift, android, and flutter sdks. ## Common functionality As we migrate the `room-apis` mode to fully use uniffi, there will inevitably be bits and pieces we want to expose to both "modes". This pull request surfaced one initial candidate - the `build_version` function. This was exposed identically in both old uniffi implementations so now this is defined once and not gated by either "mode". ## Backwards compatibility This pull request _should_ be fully backwards compatible. That means in practice that "core modules" builds will still include identifiers within that mention `uniffi` - ie, `LiveKitUniFFI` in swift, etc. I've broken out a second step to this process in #1439 which actually cuts over the names to the new `ffi` naming, but as this is a breaking change we'll need to ensure that all downstream sdks do this update in lock step. We can also choose to not merge this second step if it is going to be too disruptive and the resulting naming debt is deemed acceptable. ## TODO - [x] Fix the dual versions of prost (`prost` vs `prost_012`) which seem to have made their way in because `livekit-ffi` and `livekit-uniffi` had different versions in use. Standardize on whatever the repo uses generally. - This has been done and broken out into a separate PR (#1447) - [x] Rebase on top of `main` once #1447 merged.

1egoman marked this pull request as ready for review September 21, 2026 17:51

1egoman requested review from ladvoc and lukasIO as code owners September 21, 2026 17:51

Create upgrade_to_prost_0_14_across_the_whole_project.md

7ac8282

This comment was marked as resolved.

Sign in to view

1egoman and others added 2 commits September 21, 2026 13:56

Update .changeset/upgrade_to_prost_0_14_across_the_whole_project.md

c203e9b

Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com>

fix: upgrade livekit-uniffi prost 0.12 straggler

a65fe9d

Missed one, oops

1egoman mentioned this pull request Sep 21, 2026

Merge livekit-ffi / livekit-uniffi together into a new livekit-ffi with room-apis andcore-modules modes #1438

Merged

2 tasks done

1egoman and others added 2 commits September 21, 2026 15:56

fix: bump proto related ci infrastructure

cb0b2c3

generated protobuf

162a696

devin-ai-integration Bot reviewed Sep 21, 2026

View reviewed changes

xianshijing-lk approved these changes Sep 21, 2026

View reviewed changes

ladvoc approved these changes Sep 22, 2026

View reviewed changes

1egoman requested a review from jhugman September 22, 2026 16:44

ladvoc merged commit 8793db5 into main Sep 22, 2026
45 of 47 checks passed

ladvoc deleted the migrate-to-prost-0.14 branch September 22, 2026 20:07

1egoman mentioned this pull request Sep 24, 2026

fix(changeset): drop the duplicate livekit-uniffi key blocking the livekit-protocol release #1464

Merged

knope-bot Bot mentioned this pull request Sep 24, 2026

Release packages #1455

Merged

J3vb mentioned this pull request Sep 27, 2026

build(client): align tauri-plugin-http at 2.7.0 and move livekit to 0.9.3 J3vb/OwnCord#1902

Merged

Navigation Menu

Repository navigation

Upgrade to prost 0.14 across the whole project - #1447

Upgrade to prost 0.14 across the whole project#1447
ladvoc merged 6 commits into
mainfrom
migrate-to-prost-0.14

1egoman commented Sep 21, 2026 •

edited by ladvoc

Loading

Uh oh!

github-actions Bot commented Sep 21, 2026 •

edited

Loading

Uh oh!

This comment was marked as resolved.

Uh oh!

devin-ai-integration Bot left a comment

Uh oh!

devin-ai-integration Bot Sep 21, 2026

Uh oh!

ladvoc Sep 21, 2026 •

edited

Loading

Uh oh!

1egoman Sep 21, 2026

Uh oh!

ladvoc left a comment

Uh oh!

ladvoc commented Sep 22, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

1egoman commented Sep 21, 2026 • edited by ladvoc Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

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

Uh oh!

Changeset ✓

Uh oh!

This comment was marked as resolved.

Uh oh!

devin-ai-integration Bot left a comment

Choose a reason for hiding this comment

Uh oh!

devin-ai-integration Bot Sep 21, 2026

Choose a reason for hiding this comment

Uh oh!

ladvoc Sep 21, 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!

1egoman Sep 21, 2026

Choose a reason for hiding this comment

Uh oh!

ladvoc left a comment

Choose a reason for hiding this comment

Uh oh!

ladvoc commented Sep 22, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

1egoman commented Sep 21, 2026 •

edited by ladvoc

Loading

github-actions Bot commented Sep 21, 2026 •

edited

Loading

ladvoc Sep 21, 2026 •

edited

Loading