Declare the UTF-8 byte length in the sendText stream header - #1184
Merged
Merged
Conversation
Stahgah
requested review from
cloudwebrtc,
hiroshihorie and
xianshijing-lk
as code owners
August 29, 2026 10:33
|
|
There was a problem hiding this comment.
🔍 Devin Review: 2 flags
Not posted on this PR by your GitHub settings — view them in Devin Review. (Configure)
hiroshihorie
approved these changes
Sep 1, 2026
rokk4
added a commit
to rokk4/client-sdk-flutter
that referenced
this pull request
Sep 1, 2026
Brings in three upstream commits: 8827c32 Resolve a default audio session from engine state when no policy was pushed (livekit#1182) f014f69 Request microphone permission before audio capture starts (livekit#1183) b0e5db2 Declare the UTF-8 byte length in the sendText stream header (livekit#1184) Upstream touched none of the files this fork patches, so the only conflict was pubspec.lock (matcher, meta, test_api - all SDK-vendored). Resolved by re-resolving with Flutter 3.47.2, the SDK the consuming app builds against. The lock now differs from upstream by two lines: our flutter_webrtc 1.6.0+hotfix.1 pin, which the podspecs' WebRTC-SDK 144.7559.10 depends on. The two audio commits are Apple-platform only (LiveKitPlugin.swift); they do not overlap the Android audio-routing work in the app.
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.
Description
sendText() currently calculates the total stream size using text.codeUnits.length.
This does not correspond to the actual number of bytes produced when the text is encoded as UTF-8. As a result, messages containing non-ASCII characters such as accented characters or emojis can cause the receiver to reject the stream with:
StreamError: read length exceeded total length specified in stream header
For example, é is one UTF-16 code unit but requires two bytes in UTF-8.
Fix
Use the UTF-8 encoded byte length when setting the total stream size:
final textInBytes = utf8.encode(text);
final totalTextLength = textInBytes.length;
This ensures that the size declared in the stream header matches the actual UTF-8 payload size.
Testing
Tested with messages containing:
ASCII characters
Accented characters (é, à, è, etc.)
Emojis
Multibyte Unicode characters
Before this change, messages containing accented characters could trigger the StreamError. After the change, they are correctly received by the LiveKit Agents backend.
Related issue
Fixes #1054