1) Refactor call end handling, to explicitly process ENDED messages from VoiceConnector, rather than imputing call end from stream data ending - adds robustness when stream can end (temporarily) for other reasons (such as call hold, etc.)
2) Added the callId to the log output, so that it is easier to trace calls.
3) Added the request id of the next Lambda invocation in the output of the log, so that it makes it easier to trace sequential lambda invocations (chaining).
4) Identified a situation where if a call chained across multiple lambda invocations (lasted longer than 12 minutes), the new timer we introduced that checks if the call ends would leak into the next lambda invocation. This is why in the logs we saw multiple sequential DynamoDB checks. This would have no effect for a single long running call other than duplicate checks to DynamoDB—however—if the call ends and a NEW call uses that warm Lambda, the new call would inherit the timers and within 5 seconds mark the call as ended. To fix this, we made modifications by adding proper clean-up of timers when the call ends, and also double checking when the next call begins that the new Lambda did not inherit any calls.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Issue #, if available:
Description of changes:
1) Refactor call end handling, to explicitly process ENDED messages from VoiceConnector, rather than imputing call end from stream data ending - adds robustness when stream can end (temporarily) for other reasons (such as call hold, etc.) 2) Added the callId to the log output, so that it is easier to trace calls. 3) Added the request id of the next Lambda invocation in the output of the log, so that it makes it easier to trace sequential lambda invocations (chaining). 4) Identified a situation where if a call chained across multiple lambda invocations (lasted longer than 12 minutes), the new timer we introduced that checks if the call ends would leak into the next lambda invocation. This is why in the logs we saw multiple sequential DynamoDB checks. This would have no effect for a single long running call other than duplicate checks to DynamoDB—however—if the call ends and a NEW call uses that warm Lambda, the new call would inherit the timers and within 5 seconds mark the call as ended. To fix this, we made modifications by adding proper clean-up of timers when the call ends, and also double checking when the next call begins that the new Lambda did not inherit any calls.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.