Open david-katz opened 1 month ago
I tried adding a .catch block to the stream processing:
resp.transcriptResultStream
?.catch { e ->
if (e !is Exception) throw e
logger.error("error in transcriptResultStream: ${e.message}")
speechRecognitionResultsListener?.onError(e)
stop()
}
?.collect { event ->
but the result was that while this catch block was called, for instance when no audio was received by transcribe for 15 seconds, the StreamResetException was still unhandled.
I've been able to reproduce this and I'm working on a fix and additional testing within the SDK. I'll post an update here when I have a PR.
Circling back to this, I do believe that our use of GlobalScope
is not optimal and should be changed. That being said, I do not believe that using a better scope will affect the issue of exceptions disappearing from child jobs.
I think the problem lies in using launch
without any additional constructs which would wait on the result or propagate the exception. Without those, exceptions produced by child jobs won't block the current thread, they'll merely happen in the background and be handled by the default coroutine exception handler (which prints them to the console). I suggest using coroutineScope { }
or join()
to propagate the exception:
awsTranscribeJob =
myScope.launch(RecognitionServiceExceptionHandler) {
withContext(myDispatcher) {
try {
awsTranscribe?.start()
} catch (e: AwsTranscribeException) {
Timber.tag(RECOGNITION_LOGGING_TAG).e(e, "Error processing transcript from AWS Transcribe")
launch(Dispatchers.Main) {
givenCallback?.error(SpeechRecognizer.ERROR_SERVER)
}
} catch (e: IOException) {
Timber.tag(RECOGNITION_LOGGING_TAG).e(e, "IO error getting transcript")
launch(Dispatchers.Main) {
givenCallback?.error(SpeechRecognizer.ERROR_NETWORK)
}
}
}
}.join()
Additionally, I believe the use of SupervisorJob
here means child jobs' exceptions will not cause any error to happen outside of the scope, meaning they also will disappear. Your RecognitionServiceExceptionHandler
may be able to see they've occurred and log messages but recovery will be impossible.
Lastly, I'm unclear what AwsTranscribeException
is in the catch
clause. The Kotlin Transcribe client will throw exceptions which inherit from TranscribeStreamingException
for service-related errors, including BadRequestException
which occurs when an audio stream has been idle too long.
I don't know enough about your surrounding code and desired state to be certain but I believe your invocation of this API can be simplified to remove the explicit scope and supervisor job, handle the correct base exception type, and eliminate the need for the uncaught exception handler:
val myDispatcher = Executors
.newSingleThreadExecutor(VoiceInteractionThreadFactory)
.asCoroutineDispatcher()
awsTranscribeJob = coroutineScope {
withContext(myDispatcher) {
try {
awsTranscribe?.start()
} catch (e: TranscribeStreamingException) {
Timber.tag(RECOGNITION_LOGGING_TAG).e(e, "Error processing transcript from AWS Transcribe")
launch(Dispatchers.Main) {
givenCallback?.error(SpeechRecognizer.ERROR_SERVER)
}
} catch (e: IOException) {
Timber.tag(RECOGNITION_LOGGING_TAG).e(e, "IO error getting transcript")
launch(Dispatchers.Main) {
givenCallback?.error(SpeechRecognizer.ERROR_NETWORK)
}
}
}
}
This should enable exceptions to be caught and handled appropriately, including leaving the audio stream idle for too long.
Can you review and let me know if that resolves the exception propagation problem?
Describe the bug
An exception within a streaming sdk call is not being propagated to the caller's scope.
Regression Issue
Expected behavior
A streaming sdk call made within a given scope should propagate its exceptions back to that scope. An exception handler provided at launch should be called if the exception is not otherwise handled.
Current behavior
Exceptions that occur within the stream that are not handled within the stream are not propagated to the calling scope's exception handler. Instead the app's top-level exception handler is receiving the following as an unhandled exception:
Steps to Reproduce
The streaming call is being started within a coroutine as follows:
Possible Solution
In aws.smithy.kotlin.runtime.http.engine.okhttp.StreamingRequestBody#doWriteTo
Perhaps the GlobalScope.launch is the issue?
Context
No response
Smithy-Kotlin version
1.3.17
Platform (JVM/JS/Native)
JVM
Operating system and version
Android 13