When calling the restart() method on a ProcessorWrapper instance, a race condition can occur, leading to a fatal error in the stream processing pipeline. This issue appears to be intermittent and is more likely to happen if the associated TrackTransformer has a very fast or synchronous init() method.
The symptom is a black video for the processed track (frozen frame on participants side) and the following error in the console:
error when trying to pipe InvalidStateError: Stream closed
This happens because the cleanup logic from the previous processing session is incorrectly triggered after the new session has already begun, causing it to call destroy() a second time on the same instance.
affected code block:
private initStreamProcessorPath() {
// ...
pipedStream
.pipeTo(this.trackGenerator.writable)
.catch((e) => console.error('error when trying to pipe', e))
.finally(() => this.destroy()); // <-- Problematic line
// ...
}
A temporary workaround is to introduce an artificial async delay in the destroy() method of the transformer. This gives the old pipeline's .finally() callback time to execute before the new init() begins, making the race condition less likely. However, this is timing-dependent and not a robust solution. Better would be to only call this.destroy() in the code block above, if it happens in the current/new pipeline and not in the old one.
Note: Gemini helped with the description..
When calling the
restart()method on aProcessorWrapperinstance, a race condition can occur, leading to a fatal error in the stream processing pipeline. This issue appears to be intermittent and is more likely to happen if the associatedTrackTransformerhas a very fast or synchronous init() method.The symptom is a black video for the processed track (frozen frame on participants side) and the following error in the console:
error when trying to pipe InvalidStateError: Stream closedThis happens because the cleanup logic from the previous processing session is incorrectly triggered after the new session has already begun, causing it to call
destroy()a second time on the same instance.affected code block:
A temporary workaround is to introduce an artificial async delay in the destroy() method of the transformer. This gives the old pipeline's .finally() callback time to execute before the new init() begins, making the race condition less likely. However, this is timing-dependent and not a robust solution. Better would be to only call
this.destroy()in the code block above, if it happens in the current/new pipeline and not in the old one.Note: Gemini helped with the description..