No, I think this is just a plain old bug – I probably just need to make sure there are no cases in which this happens after a failure is returned:
PocketsphinxController will still return isListening = YES
I actually can’t see how that is possible when reviewing the current code – every failure calls performContinuousFailureStopForIssue: and every call of that method sets isListening to FALSE, but it can get some testing after WWDC to see why the promise isn’t being fulfilled under that circumstance of a call interruption. Broadly, the idea is that you’ll keep the same instance around for your whole session and it will deal with exceptions politely and not have issues toggling between a started and a stopped state even if there has been a failure. I appreciate hearing about cases where this isn’t working yet.
(for example I have found that if I call [pocketsphinxController stopListening] and set it to nil while it is calibrating that this can cause crashes if a new controller is created too soon).
Sorry, not quite following this yet – why is it being set to nil while it is calibrating and/or why is it calibrating while it is stopping?
To set it to nil, first ask it to stop and then when you have a callback in the OpenEarsEventsObserver method pocketsphinxDidStopListening you can set it to nil if you like. Until that callback, it is busy safely winding down its threads and it won’t be safe to stop.