Release packages

[knope-bot]

Important

Merging this pull request will create these releases

livekit-token 0.2.0 (2026-09-20)

Breaking Changes

VideoGrants gains the agent grant and Claims the kind claim (with

AccessToken::with_kind), which the Go, Python and JS SDKs already carry. An
agent worker's token is VideoGrants { agent: true } and a simulated job's
participant token is kind: "agent"; neither could be minted from Rust before.
livekit-uniffi exposes both: TokenOptions.kind, Claims.kind, and agent
on its VideoGrants record.

Breaking: the four grants the server infers when absent -- can_publish,
can_subscribe, can_publish_data, can_update_own_metadata -- are now
Option<bool>, as in the Go and JS SDKs. None leaves the decision to the
server, and the new getters (can_publish(), can_subscribe(),
can_publish_data(), can_update_own_metadata()) read a token the way the
server does, can_publish_data falling back to can_publish included. Code
that set these fields writes Some(..); code that read them uses the getters.
The same fields are optional on the livekit-uniffi record, and
livekit-api re-exports the crate as livekit_api::access_token, so both
carry the change.

Nothing at its default is written into the token any more: unset claims and
grants are omitted, as the server's own omitempty grants are. Verification
of existing tokens is unchanged.

livekit-capture 0.1.2 (2026-09-20)

Features

• Add a capture source that renders a wall clock on the GPU.
• Add a capture source that renders a test pattern on the GPU.

Fixes

• Automatic capture thread join on drop
• Stop answering a server-initiated Leave (room deleted, duplicate identity) with a client Leave. The server has already ended the session and is closing the signalling socket, so the reply only ever produced the warning "dropping pass-through signal — no stream available" on every such disconnect.

EncryptionError::Failed and DecryptionError::Failed carry a reason string and are no longer flat_error,

so a foreign EncryptionProvider or DecryptionProvider returning an error no longer aborts the process with
"Can't lift flat errors" -- a failed data track decrypt (no E2EE manager, key mismatch, corrupt frame) now
drops the frame and leaves the room connected.

Report the reconnect reason to the server when resuming.

Resumes previously sent no reason, so server-side telemetry could not attribute why Rust
clients reconnect — every resume looked like RR_UNKNOWN. The engine now records what caused
the episode (signal disconnected, publisher failed, subscriber failed) and reports it on each
resume attempt. The v0 signalling path was also missing the reconnect_reason query parameter
entirely, so it would not have been reported even if a reason had been supplied.

Fix resume reporting success for a PeerConnection that had not recovered.

A resume decided recovery from PeerConnectionState, which keeps reading Connected for tens
of seconds after the far end goes away. A resume could therefore emit Resumed — and so
RoomEvent::Reconnected with ConnectionState::Connected — for a session whose subscriber
transport was dead, leaving applications with no signal that they had stopped receiving media.
A resume now requires each transport to have entered Connected since the resume began, or to
have held it throughout, rather than trusting the state it currently reports.

livekit-signaling 0.1.3 (2026-09-20)

Fixes

Report the reconnect reason to the server when resuming.

Resumes previously sent no reason, so server-side telemetry could not attribute why Rust
clients reconnect — every resume looked like RR_UNKNOWN. The engine now records what caused
the episode (signal disconnected, publisher failed, subscriber failed) and reports it on each
resume attempt. The v0 signalling path was also missing the reconnect_reason query parameter
entirely, so it would not have been reported even if a reason had been supplied.

VideoGrants gains the agent grant and Claims the kind claim (with

AccessToken::with_kind), which the Go, Python and JS SDKs already carry. An
agent worker's token is VideoGrants { agent: true } and a simulated job's
participant token is kind: "agent"; neither could be minted from Rust before.
livekit-uniffi exposes both: TokenOptions.kind, Claims.kind, and agent
on its VideoGrants record.

Breaking: the four grants the server infers when absent -- can_publish,
can_subscribe, can_publish_data, can_update_own_metadata -- are now
Option<bool>, as in the Go and JS SDKs. None leaves the decision to the
server, and the new getters (can_publish(), can_subscribe(),
can_publish_data(), can_update_own_metadata()) read a token the way the
server does, can_publish_data falling back to can_publish included. Code
that set these fields writes Some(..); code that read them uses the getters.
The same fields are optional on the livekit-uniffi record, and
livekit-api re-exports the crate as livekit_api::access_token, so both
carry the change.

Nothing at its default is written into the token any more: unset claims and
grants are omitted, as the server's own omitempty grants are. Verification
of existing tokens is unchanged.

livekit-api 0.8.0 (2026-09-20)

Breaking Changes

VideoGrants gains the agent grant and Claims the kind claim (with

AccessToken::with_kind), which the Go, Python and JS SDKs already carry. An
agent worker's token is VideoGrants { agent: true } and a simulated job's
participant token is kind: "agent"; neither could be minted from Rust before.
livekit-uniffi exposes both: TokenOptions.kind, Claims.kind, and agent
on its VideoGrants record.

Breaking: the four grants the server infers when absent -- can_publish,
can_subscribe, can_publish_data, can_update_own_metadata -- are now
Option<bool>, as in the Go and JS SDKs. None leaves the decision to the
server, and the new getters (can_publish(), can_subscribe(),
can_publish_data(), can_update_own_metadata()) read a token the way the
server does, can_publish_data falling back to can_publish included. Code
that set these fields writes Some(..); code that read them uses the getters.
The same fields are optional on the livekit-uniffi record, and
livekit-api re-exports the crate as livekit_api::access_token, so both
carry the change.

Nothing at its default is written into the token any more: unset claims and
grants are omitted, as the server's own omitempty grants are. Verification
of existing tokens is unchanged.

Fixes

Report the reconnect reason to the server when resuming.

Resumes previously sent no reason, so server-side telemetry could not attribute why Rust
clients reconnect — every resume looked like RR_UNKNOWN. The engine now records what caused
the episode (signal disconnected, publisher failed, subscriber failed) and reports it on each
resume attempt. The v0 signalling path was also missing the reconnect_reason query parameter
entirely, so it would not have been reported even if a reason had been supplied.

livekit-datatrack 0.1.16 (2026-09-20)

Features

EncryptionError::Failed and DecryptionError::Failed carry a reason string and are no longer flat_error,

so a foreign EncryptionProvider or DecryptionProvider returning an error no longer aborts the process with
"Can't lift flat errors" -- a failed data track decrypt (no E2EE manager, key mismatch, corrupt frame) now
drops the frame and leaves the room connected.

livekit-uniffi 0.2.0 (2026-09-20)

Breaking Changes

VideoGrants gains the agent grant and Claims the kind claim (with

AccessToken::with_kind), which the Go, Python and JS SDKs already carry. An
agent worker's token is VideoGrants { agent: true } and a simulated job's
participant token is kind: "agent"; neither could be minted from Rust before.
livekit-uniffi exposes both: TokenOptions.kind, Claims.kind, and agent
on its VideoGrants record.

Breaking: the four grants the server infers when absent -- can_publish,
can_subscribe, can_publish_data, can_update_own_metadata -- are now
Option<bool>, as in the Go and JS SDKs. None leaves the decision to the
server, and the new getters (can_publish(), can_subscribe(),
can_publish_data(), can_update_own_metadata()) read a token the way the
server does, can_publish_data falling back to can_publish included. Code
that set these fields writes Some(..); code that read them uses the getters.
The same fields are optional on the livekit-uniffi record, and
livekit-api re-exports the crate as livekit_api::access_token, so both
carry the change.

Nothing at its default is written into the token any more: unset claims and
grants are omitted, as the server's own omitempty grants are. Verification
of existing tokens is unchanged.

Features

EncryptionError::Failed and DecryptionError::Failed carry a reason string and are no longer flat_error,

so a foreign EncryptionProvider or DecryptionProvider returning an error no longer aborts the process with
"Can't lift flat errors" -- a failed data track decrypt (no E2EE manager, key mismatch, corrupt frame) now
drops the frame and leaves the room connected.

Fixes

Report the reconnect reason to the server when resuming.

Resumes previously sent no reason, so server-side telemetry could not attribute why Rust
clients reconnect — every resume looked like RR_UNKNOWN. The engine now records what caused
the episode (signal disconnected, publisher failed, subscriber failed) and reports it on each
resume attempt. The v0 signalling path was also missing the reconnect_reason query parameter
entirely, so it would not have been reported even if a reason had been supplied.

livekit 0.9.2 (2026-09-20)

Fixes

• Stop answering a server-initiated Leave (room deleted, duplicate identity) with a client Leave. The server has already ended the session and is closing the signalling socket, so the reply only ever produced the warning "dropping pass-through signal — no stream available" on every such disconnect.

EncryptionError::Failed and DecryptionError::Failed carry a reason string and are no longer flat_error,

so a foreign EncryptionProvider or DecryptionProvider returning an error no longer aborts the process with
"Can't lift flat errors" -- a failed data track decrypt (no E2EE manager, key mismatch, corrupt frame) now
drops the frame and leaves the room connected.

Report the reconnect reason to the server when resuming.

Resumes previously sent no reason, so server-side telemetry could not attribute why Rust
clients reconnect — every resume looked like RR_UNKNOWN. The engine now records what caused
the episode (signal disconnected, publisher failed, subscriber failed) and reports it on each
resume attempt. The v0 signalling path was also missing the reconnect_reason query parameter
entirely, so it would not have been reported even if a reason had been supplied.

Fix resume reporting success for a PeerConnection that had not recovered.

A resume decided recovery from PeerConnectionState, which keeps reading Connected for tens
of seconds after the far end goes away. A resume could therefore emit Resumed — and so
RoomEvent::Reconnected with ConnectionState::Connected — for a session whose subscriber
transport was dead, leaving applications with no signal that they had stopped receiving media.
A resume now requires each transport to have entered Connected since the resume began, or to
have held it throughout, rather than trusting the state it currently reports.

VideoGrants gains the agent grant and Claims the kind claim (with

AccessToken::with_kind), which the Go, Python and JS SDKs already carry. An
agent worker's token is VideoGrants { agent: true } and a simulated job's
participant token is kind: "agent"; neither could be minted from Rust before.
livekit-uniffi exposes both: TokenOptions.kind, Claims.kind, and agent
on its VideoGrants record.

Breaking: the four grants the server infers when absent -- can_publish,
can_subscribe, can_publish_data, can_update_own_metadata -- are now
Option<bool>, as in the Go and JS SDKs. None leaves the decision to the
server, and the new getters (can_publish(), can_subscribe(),
can_publish_data(), can_update_own_metadata()) read a token the way the
server does, can_publish_data falling back to can_publish included. Code
that set these fields writes Some(..); code that read them uses the getters.
The same fields are optional on the livekit-uniffi record, and
livekit-api re-exports the crate as livekit_api::access_token, so both
carry the change.

Nothing at its default is written into the token any more: unset claims and
grants are omitted, as the server's own omitempty grants are. Verification
of existing tokens is unchanged.

livekit-ffi 0.12.80 (2026-09-20)

Features

• Add the scaffolding for exposing video capture over FFI.
• Add a capture source that renders a wall clock on the GPU.
• Add a capture source that renders a test pattern on the GPU.

Fixes

• Stop answering a server-initiated Leave (room deleted, duplicate identity) with a client Leave. The server has already ended the session and is closing the signalling socket, so the reply only ever produced the warning "dropping pass-through signal — no stream available" on every such disconnect.

EncryptionError::Failed and DecryptionError::Failed carry a reason string and are no longer flat_error,

so a foreign EncryptionProvider or DecryptionProvider returning an error no longer aborts the process with
"Can't lift flat errors" -- a failed data track decrypt (no E2EE manager, key mismatch, corrupt frame) now
drops the frame and leaves the room connected.

Report the reconnect reason to the server when resuming.

Resumes previously sent no reason, so server-side telemetry could not attribute why Rust
clients reconnect — every resume looked like RR_UNKNOWN. The engine now records what caused
the episode (signal disconnected, publisher failed, subscriber failed) and reports it on each
resume attempt. The v0 signalling path was also missing the reconnect_reason query parameter
entirely, so it would not have been reported even if a reason had been supplied.

Fix resume reporting success for a PeerConnection that had not recovered.

A resume decided recovery from PeerConnectionState, which keeps reading Connected for tens
of seconds after the far end goes away. A resume could therefore emit Resumed — and so
RoomEvent::Reconnected with ConnectionState::Connected — for a session whose subscriber
transport was dead, leaving applications with no signal that they had stopped receiving media.
A resume now requires each transport to have entered Connected since the resume began, or to
have held it throughout, rather than trusting the state it currently reports.

VideoGrants gains the agent grant and Claims the kind claim (with

AccessToken::with_kind), which the Go, Python and JS SDKs already carry. An
agent worker's token is VideoGrants { agent: true } and a simulated job's
participant token is kind: "agent"; neither could be minted from Rust before.
livekit-uniffi exposes both: TokenOptions.kind, Claims.kind, and agent
on its VideoGrants record.

Breaking: the four grants the server infers when absent -- can_publish,
can_subscribe, can_publish_data, can_update_own_metadata -- are now
Option<bool>, as in the Go and JS SDKs. None leaves the decision to the
server, and the new getters (can_publish(), can_subscribe(),
can_publish_data(), can_update_own_metadata()) read a token the way the
server does, can_publish_data falling back to can_publish included. Code
that set these fields writes Some(..); code that read them uses the getters.
The same fields are optional on the livekit-uniffi record, and
livekit-api re-exports the crate as livekit_api::access_token, so both
carry the change.

Nothing at its default is written into the token any more: unset claims and
grants are omitted, as the server's own omitempty grants are. Verification
of existing tokens is unchanged.

[devin-ai-integration]

Note

This report is out of date. Scroll down for Devin Review's latest report on this PR.

🔍 Devin Review: 1 flag

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

[devin-ai-integration]

Note

This report is out of date. Scroll down for Devin Review's latest report on this PR.

Devin Review found 1 new potential issue.

🐛 1 issue in files not directly in the diff

🐛 Dropped pumps leave threads detached

When a source remains blocked, RunningPump::drop only signals stop and detaches the join handle. The thread and captured resources can remain alive indefinitely.

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

[devin-ai-integration]

Devin Review found 1 new potential issue.

2 flags not posted on this PR by your GitHub settings — view them in Devin Review. (Configure)

[devin-ai-integration]

🟡 Patch release breaks Rust consumers

A ^0.1.15 dependency can resolve 0.1.16, but both error Failed variants changed from unit to struct variants. Existing Rust consumers then fail to compile after a compatible update.

Learn more

Cargo treats releases within 0.1.x as semver-compatible. The error variants are public through the crate's backend API, and changing a unit variant to a struct variant breaks both construction and pattern matching. A resolver can therefore upgrade existing consumers automatically and hand them source that no longer compiles.

Example: A consumer declaring livekit-datatrack = "0.1.15" and matching EncryptionError::Failed can receive 0.1.16 during a lockfile update. Its unchanged match no longer compiles because the variant now requires { reason }.

Recommended fix: Release livekit-datatrack as 0.2.0 and update the workspace dependency and every generated release reference accordingly. Alternatively, preserve the existing Rust variant shape while introducing a separate UniFFI-facing error type.

Suggested change

	version = "0.1.16"
	version = "0.2.0"

---

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