Skip to content

Address data streams e2e test failure #749

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
1egoman merged 2 commits into from
Oct 19, 2026
Merged

Address data streams e2e test failure #749

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e9dff31
fix: address data streams e2e test failure
1egoman Oct 19, 2026
0bc6d84
test: tolerate a clean end-of-stream when the room disconnects
1egoman Oct 19, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 10 additions & 7 deletions packages/livekit-rtc/src/tests/e2e_data_streams.test.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -477,12 +477,13 @@ describeE2E('livekit-rtc data streams e2e', () => {
expect(subscribedReaderCount(receivingRoom!)).toBe(0);

// The read settles rather than hanging. Which way it settles is a race
// the SDK doesn't control: the native side emits a clean end-of-stream
// when the room drops the stream (livekit-ffi `read_incremental` sends
// `eos { error: None }` once the channel closes), so either that lands
// first and the read returns the chunks buffered so far, or disconnect
// cleanup errors the stream first and the read reports that. Python is
// deterministic here because it injects a synthetic error end-of-stream.
// the SDK doesn't control: the native side aborts in-flight streams when
// the room shuts down (livekit-ffi sends `eos` with a
// `StreamError::AbnormalEnd`), while disconnect cleanup errors the stream
// from the JS side. Whichever lands first wins. CI has also seen a clean
// `eos` land first, ending the read with the chunks buffered so far;
// that's unexpected after the native abort-on-shutdown change and is
// still being investigated, so it's tolerated here for now.
const readResult = await withTimeout(
reader.readAll().then(
(text) => ({ text }),
Expand All @@ -492,7 +493,9 @@ describeE2E('livekit-rtc data streams e2e', () => {
'Timed out reading a reader whose room disconnected',
);
if ('err' in readResult) {
expect(String(readResult.err)).toMatch(/Disconnected while receiving/);
expect(String(readResult.err)).toMatch(
/Disconnected while receiving|stream closed abnormally: Data stream connection closed/,
);
} else {
expect('buffered data'.startsWith(readResult.text)).toBe(true);
}
Expand Down