Fix race condition causing "Writer is not bound to a WritableStream" error in Silero VAD #786

toubatbrian · 2025-10-24T09:05:03Z

Problem

The Silero VAD plugin was intermittently throwing unhandled TypeError: Invalid state: Writer is not bound to a WritableStream errors when plugin close.

Root Cause

A race condition exists between the VAD inference loop and the stream shutdown process:

The VAD task runs in a continuous loop, checking while (!this.closed) before processing frames
When a participant disconnects, the base class close() method:
- Calls outputWriter.releaseLock() to unbind the writer from the stream
- Sets closed = true
These operations are not atomic, creating a window where the inference loop can pass the !this.closed check but then attempt to write to an already-released writer

Race Condition Timeline:

VAD Task                     |  Close Task
-----------------------------|---------------------------
Check: !this.closed → true   |
                             |  outputWriter.releaseLock()
                             |  closed = true
outputWriter.write(...) ❌   |
→ Writer is not bound!       |

Solution

Implemented graceful error handling following the established pattern in deferred_stream.ts.

changeset-bot · 2025-10-24T09:05:07Z

🦋 Changeset detected

Latest commit: dbb6c0e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@livekit/agents-plugin-silero	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Shubhrakanti

You mention that the Close Thread calls outputWriter.releaseLock() .... closed = true but we don't multi thread? It's asynchronous. Are you sure this is the root cause?

Are you able to reliably reproduce this issue? If so can you list the steps?

toubatbrian · 2025-10-24T18:06:44Z

You mention that the Close Thread calls outputWriter.releaseLock() .... closed = true but we don't multi thread? It's asynchronous. Are you sure this is the root cause?

Yes, I'm pretty sure. This is "async interleaving", there are await inside the this.#task promise:

await this.inputReader.read() 
await this.#model.run(inferenceData)

both yield control back to the event loop.

Here's how the race condition occurs:

VAD inference loop passes the while (!this.closed) check
Execution reaches one of the await points → yields control to event loop
While yielded, event loop processes a participant disconnect event
This triggers close() which runs synchronously:
this.outputWriter.releaseLock() unbinds writer
Event loop resumes the VAD task after the await completes
Execution continues past the !this.closed check but before checking again, code attempts this.outputWriter.write() → Error: Writer is not bound

theomonnom · 2025-10-24T18:26:18Z

plugins/silero/src/vad.ts

+function isWriterReleaseError(e: unknown): boolean {
+  if (e instanceof TypeError) {
+    // Check for ERR_INVALID_STATE error code (most reliable)
+    if ('code' in e && e.code === 'ERR_INVALID_STATE') {
+      return true;
+    }
+
+    // Fallback to message checking for compatibility
+    const message = e.message;
+    return (
+      message.includes('Writer is not bound to a WritableStream') ||
+      message.includes('WritableStream is closed')
+    );
+  }
+  return false;
+}


Isn't this hacky? Should we have another mechanism of synchronization?

We have similar approach in defered_stream.ts

agents-js/agents/src/stream/deferred_stream.ts

Lines 17 to 28 in 7fc7808

export function isStreamReaderReleaseError(e: unknown) {

const allowedMessages = [

'Invalid state: Releasing reader',

'Invalid state: The reader is not attached to a stream',

];

if (e instanceof TypeError) {

return allowedMessages.some((message) => e.message.includes(message));

}

return false;

}

The error we're catching (ERR_INVALID_STATE: Writer is not bound) is essentially Node.js telling us the stream is shutting down. It's not really an exceptional condition, it's an expected part of the shutdown sequence that we need to handle gracefully. The safeWriteEvent() method makes this explicit: it catches expected shutdown errors and signals the loop to exit cleanly, while still throwing any truly unexpected errors.

Could this happen in llm/stt/tts as well?

Shubhrakanti

@toubatbrian I think this is what you mean. We have a to await the model to actually run during which the outputWriter might be closed.

(model run)

agents-js/plugins/silero/src/vad.ts

Lines 221 to 223 in 7fc7808

    
           const p = await this.#model 
        
             .run(inferenceData) 
        
             .then((data) => this.#expFilter.apply(1, data));

(output writer definition)

agents-js/agents/src/vad.ts

Line 91 in 7fc7808

protected outputWriter: WritableStreamDefaultWriter<VADEvent>;

Is there a simpler solution where the base vad class has a method that wraps this.outputWriter.write with a if (!this.closed)? Then every plugin just calls this method and doesn't have to worry about the internals of outputWriter?

toubatbrian · 2025-10-24T20:11:41Z

Is there a simpler solution where the base vad class has a method that wraps this.outputWriter.write with a if (!this.closed)? Then every plugin just calls this method and doesn't have to worry about the internals of outputWriter?

@Shubhrakanti Great question! Let's definitely explore that idea later. For now let's focus on fixing the VAD issue within the scope of this PR to unblock our customer first. We can revisit and discuss a cleaner solution afterward.

Shubhrakanti · 2025-10-24T20:15:53Z

Is there a simpler solution where the base vad class has a method that wraps this.outputWriter.write with a if (!this.closed)? Then every plugin just calls this method and doesn't have to worry about the internals of outputWriter?

@Shubhrakanti Great question! Let's definitely explore that idea later. For now let's focus on fixing the VAD issue within the scope of this PR to unblock our customer first. We can revisit and discuss a cleaner solution afterward.

All we need to do is add one method to the base vad class

writeOutput(event: VADEvent) {
    if (!this.closed) {
       this.outputWriter.write(event)
    } else {
     // you can either throw an error or have a boolean which returns if the write was successful or not. Or just do nothing and the next iteration of `this.#task` in silerio.vad the main loop will break since `this.close == true`
   ....
}

and then you replace this.outputWriter.write( -> this.writeOutput in sliero/vad.ts.

It's fine if this goes out Mondaynext week. I'd rather have it done correctly.

Shubhrakanti

Looks a lot cleaner. Just a few questions that would be good to get the answer for. Mainly behind why we still need isWriterReleaseError. Can't we just sync the writer state with this.closed? cc: @theomonnom - let me know if I'm focussing on the wrong details here.

Shubhrakanti · 2025-10-27T17:50:46Z

agents/src/vad.ts

+      return true;
+    } catch (e) {
+      // Ignore writer release errors during stream closure (e.g., on participant disconnect)
+      if (isWriterReleaseError(e)) {


If this.closed is false then the writer should not be closed right? We should never see this error?

I think we can drop this, but I’m keeping it for now as an extra safety measure.

Let's drop it for now. If we see this error again that means the writer state is out of sync with this.closed. We want to know that so we can fix it.

plugins/silero/src/vad.ts

Shubhrakanti

Please look at the two comments before merging.

Shubhrakanti · 2025-10-28T14:41:15Z

plugins/silero/src/vad.ts

+              if (
+                !this.sendVADEvent({


if (!this.sendVADEvent) { continue }

Feels redundant? We can just do this.sendVADEvent? We don't need a return type?

toubatbrian added 2 commits October 24, 2025 17:00

Update vad.ts

f2f90c5

Update vad.ts

88b3587

toubatbrian added 2 commits October 24, 2025 17:06

Create soft-memes-drive.md

0dcdf13

Update vad.ts

4db5c8f

toubatbrian requested a review from Shubhrakanti October 24, 2025 09:10

Shubhrakanti reviewed Oct 24, 2025

View reviewed changes

toubatbrian requested a review from Shubhrakanti October 24, 2025 18:07

theomonnom reviewed Oct 24, 2025

View reviewed changes

toubatbrian requested a review from davidzhao October 24, 2025 18:28

Shubhrakanti requested changes Oct 24, 2025

View reviewed changes

save

226ba74

Shubhrakanti reviewed Oct 27, 2025

View reviewed changes

Update vad.ts

dbb6c0e

toubatbrian requested a review from Shubhrakanti October 28, 2025 02:38

Shubhrakanti approved these changes Oct 28, 2025

View reviewed changes

	export function isStreamReaderReleaseError(e: unknown) {
	const allowedMessages = [
	'Invalid state: Releasing reader',
	'Invalid state: The reader is not attached to a stream',
	];

	if (e instanceof TypeError) {
	return allowedMessages.some((message) => e.message.includes(message));
	}

	return false;
	}

	const p = await this.#model
	.run(inferenceData)
	.then((data) => this.#expFilter.apply(1, data));

Uh oh!

Fix race condition causing "Writer is not bound to a WritableStream" error in Silero VAD #786

Are you sure you want to change the base?

Fix race condition causing "Writer is not bound to a WritableStream" error in Silero VAD #786

Uh oh!

Conversation

toubatbrian commented Oct 24, 2025 • edited by Shubhrakanti Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Root Cause

Solution

Uh oh!

changeset-bot bot commented Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

Shubhrakanti left a comment

Choose a reason for hiding this comment

Uh oh!

toubatbrian commented Oct 24, 2025

Uh oh!

theomonnom Oct 24, 2025

Choose a reason for hiding this comment

Uh oh!

toubatbrian Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

toubatbrian Oct 24, 2025

Choose a reason for hiding this comment

Uh oh!

Shubhrakanti Oct 24, 2025

Choose a reason for hiding this comment

Uh oh!

Shubhrakanti left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

toubatbrian commented Oct 24, 2025

Uh oh!

Shubhrakanti commented Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Shubhrakanti left a comment

Choose a reason for hiding this comment

Uh oh!

Shubhrakanti Oct 27, 2025

Choose a reason for hiding this comment

Uh oh!

toubatbrian Oct 28, 2025

Choose a reason for hiding this comment

Uh oh!

Shubhrakanti Oct 28, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Shubhrakanti left a comment

Choose a reason for hiding this comment

Uh oh!

Shubhrakanti Oct 28, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

toubatbrian commented Oct 24, 2025 •

edited by Shubhrakanti

Loading

changeset-bot bot commented Oct 24, 2025 •

edited

Loading

toubatbrian Oct 24, 2025 •

edited

Loading

Shubhrakanti left a comment •

edited

Loading

Shubhrakanti commented Oct 24, 2025 •

edited

Loading