diff --git a/packages/livekit-rtc/src/tests/e2e_data_streams.test.ts b/packages/livekit-rtc/src/tests/e2e_data_streams.test.ts index 628f429c..b1cb5f4d 100644 --- a/packages/livekit-rtc/src/tests/e2e_data_streams.test.ts +++ b/packages/livekit-rtc/src/tests/e2e_data_streams.test.ts @@ -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 }), @@ -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); }