ReceivedMessage missing isFinal — no way to know when a segment is done streaming

[acrdlph]

Describe the bug

ReceivedMessage does not expose whether a segment has been finalized. The lk.transcription_final attribute is read internally by TranscriptionStreamReceiver (to clean up partialMessages), but it is stripped before the message reaches consumers via Session.messages.

This makes it impossible for UI code to distinguish a segment that is still streaming from one that is complete. Common use cases that require this signal:

• Showing action buttons (play, translate) only after a segment finishes
• Triggering auto-translation of completed segments
• Gating per-message interactions to avoid acting on partial text

Observed behavior

For user transcripts, lk.transcription_final transitions from "false" to "true" in the stream attributes — so the attribute-based path works.

For agent transcripts, the attribute is "false" on every chunk. Finality is implicit: the text stream closes when the segment is done. But this stream-close event is not surfaced to consumers — the for try await message in reader loop simply ends, and no final ReceivedMessage is emitted.

Additionally, the last agent segment's stream often does not close promptly. In testing, it stays open until external activity occurs (e.g. the user starts speaking or the next agent turn begins), leaving the final segment stuck in a "streaming" state indefinitely.

Server

• LiveKit Cloud, version 1.9.12
• Region: Germany 2

Client

• SDK: iOS (client-sdk-swift)
• Version: 2.12.1

To Reproduce

1. Connect to a room with a voice agent (livekit-agents Python, agents >= 1.0)
2. Agent speaks a multi-segment response (3+ bubbles)
3. Observe Session.messages — all ReceivedMessage values have no isFinal property
4. There is no way to determine when each segment's text is complete vs. still being appended

Expected behavior

ReceivedMessage should expose an isFinal: Bool property so consumers can react to segment completion. Two signals should set it to true:

1. Attribute-based: When lk.transcription_final is "true" in the stream attributes (already works for user transcripts)
2. Stream-close: When the text stream ends, the segment is implicitly finalized — a final ReceivedMessage with isFinal: true should be emitted

Proposed fix

We've been running a local patch that works well. The change is minimal (3 files, additive only, non-breaking):

1. Add public let isFinal: Bool to ReceivedMessage (default false, backward-compatible Codable)
2. Pass through isFinal from attributes in processIncoming
3. After the stream's for try await loop ends, yield one final ReceivedMessage(isFinal: true) if not already marked

Remaining issue even with the patch

The stream-close signal works reliably for middle segments (the stream closes when the next segment's stream opens). However, the last segment's stream often stays open well beyond when the agent has finished speaking — sometimes not closing until the user speaks next. A client-side debounce (act after ~1.5s of no text changes) works as a fallback, but ideally the server/agent would close the stream promptly when the segment is complete.

Additional context

• TranscriptionSegment (used in the deprecated delegate path) already has isFinal: Bool — this is just about surfacing the equivalent on the stream-based ReceivedMessage
• The default value of false makes this fully backward-compatible
• Happy to open a PR if this direction looks right

[pblazej]

@1egoman I think this is missing in JS as well, for me this is the biggest blocker:

the last segment's stream often stays open well beyond when the agent has finished speaking — sometimes not closing until the user speaks next.

@acrdlph is it working reliably for you (aka could it be the only signal): lk.transcription_final is "true"?

[acrdlph]

@pblazej yes with the described workaround it's working smoothly for me!

[pblazej]

I think we cannot do any better here and the change is purely additive 👍

Would be great if you can open a PR. My only hint is please add it to TranscriptionTests if possible.

@acrdlph