Closed KatieWoe closed 3 years ago
This seems pretty rare, and I am not sure what is causing it yet. Fuzzing on my local machine with the same query parameters isn't showing it, and it isn't in the last 10 CT collumns.
But I have seen this once before as well on CT before the snapshot @KatieWoe posted so I don't think it is gone.
The case that we are running into is this in Timer.setTimeout
// make sure that this callback hasn't already been removed by another listener while emit() is in progress
if ( this.hasListener( callback ) ) {
listener();
this.removeListener( callback );
}
The listener must be removing itself so this.removeListener
errors out.
I am seeing this in GFL:B as well in the last 10 CT cycles, must not be specific to this sim. Going to try to get it to happen there.
Found more information about why this is happening:
When a speech request is made, something is causing the queue to synchronously clear (and therefore remove timer listeners) from within the setTimeout listener.
I found it. What is happening is:
error
event triggers. voicingManager.endSpeakingEmitter
fires from that event.endSpeakingEmitter
being called on the error event seems correct to me, and I don't think there is anything wrong about the client usage. I think we need to be more graceful in voicingManager by not removing the listener in cancel() if cancel was initiated immediately from a request to speak.
This was fixed in the above commit. I was able to step through the problematic case and verify that the listener was not removed twice, but was successfully removed once at the end of the callback. Closing.