This application provides a set of Lambda functions, which are available within your Amazon Connect instance after provisioning the instance with your Service Cloud Voice contact center. You can use these Lambdas in Amazon Connect contact flows.
There seems to be a problem with the default configuration of the VoiceMailPackagingFunction lambda. The default lambda timeout is 60s as can be seen here in the yaml
However the function appears likely to always take longer than this because there is a default delay configured here (of 60s) and delay_before_routing_vm_sec isn't set or even mentioned in documentation.
Which, if I understand correctly is always going to try to wait blowing the default lambda timeout budget.
I suggest the following improvements:
A sensible default timeout if we want the function to wait at least 60s in the handler. ~ 5 minutes based on MAX_ROUTING_ATTEMPTS = 4 and 60s default delay per try plus some time.
Update the documentation to discuss these delays and timeouts to at least call out their existence and purpose.
The current default configuration is very likely to trip up everyone who uses it.
There seems to be a problem with the default configuration of the
VoiceMailPackagingFunction
lambda. The default lambda timeout is 60s as can be seen here in the yamlhttps://github.com/service-cloud-voice/ServiceCloudVoiceLambdas/blob/169a7180e329afeda947e4f61e1102bbe7f912b0/ServerlessApplication/ServiceCloudVoiceLambdas.yaml#L1440-L1454
However the function appears likely to always take longer than this because there is a default delay configured here (of 60s) and
delay_before_routing_vm_sec
isn't set or even mentioned in documentation.https://github.com/service-cloud-voice/ServiceCloudVoiceLambdas/blob/169a7180e329afeda947e4f61e1102bbe7f912b0/voiceMailPackaging/handler.js#L13
It is used down deeper in the handler here
https://github.com/service-cloud-voice/ServiceCloudVoiceLambdas/blob/169a7180e329afeda947e4f61e1102bbe7f912b0/voiceMailPackaging/handler.js#L161-L178
Which, if I understand correctly is always going to try to wait blowing the default lambda timeout budget.
I suggest the following improvements:
The current default configuration is very likely to trip up everyone who uses it.