UMS AWS Lex Plugin (v1) - DependencyFailedException issue when Lex bot uses a Fulfilment lambda

[Daniel Ng]

Hi Arsen,

Hope you are well.  I'm using the Unimrcp server and Unimrcp AWS Lex (v1) plugin (installed from the Unimrcp Redhat/CentOS repo in early Dec 2021 so should be the latest available version - 1.7.0? if I remember correctly) and this is connecting to the Cisco CVP IVR.

I've set the Lex configuration for the SDK to "6" and the unimrcp logging to debug level but currently stuck with an issue where if I enabled an AWS lambda function for fulfilment, the Unimrcp plugin encounters an issue (at least I think it is in the Unimrcp side) of DependencyFailedException.

This is what I see in the Unimrcp logs:

2022-01-10 14:37:03:585126 [INFO]   PostContentAsync: bot-name [acctNumLexVone] alias [Prod] user-id [41790df027724d3c] content-type [audio/lpcm; sample-rate=8000; sample-size-bits=16; channel-count=1; is-big-endian=false] accept [text/plain; charset=utf-8] request-attribs [{}] credentials-profile [default] <41790df027724d3c@lex>
2022-01-10 14:37:05:008345 [DEBUG]  Content Handler Called <41790df027724d3c@lex>
2022-01-10 14:37:05:008391 [WARN]   Failed to Post Content: error [DependencyFailedException] exception [The server encountered an error processing the Lambda response] <41790df027724d3c@lex>
2022-01-10 14:37:05:008459 [DEBUG]  Process Error Response <41790df027724d3c@lex>

Initially I thought that this was a Lex error that was passed through to the Unimrcp but I've stripped down the Lambda function until it is literally:

exports.handler = async (event) => {
     //Debug
    console.log("Received [" + JSON.stringify(event) + "]");

    var sessionAttributes = event['sessionAttributes'] || {};
    console.log(sessionAttributes);

    var response = {
        sessionAttributes,
        "dialogAction":{
            "type":"Close",
            "fulfillmentState": "Fulfilled"
        }
    };
   
    //var response = {
    //    "dialogAction":{
    //        "type":"Close",
    //        "fulfillmentState": "Fulfilled"
    //    }
    //};
   
    console.log("Returning [" + JSON.stringify(response) + "]");
   
    return response;
};

As you can see, as per AWS Lex/Lambda developer guide (for v1), I'm literally sending back the minimum required response for dialogAction type Close.

In the AWS Cloudwatch, I get the expected logs for the lambda function and the Lex bots which do not show any errors.  The logs look as expected and I've compared them against the same logs where I do not invoke the fulfilment lambda function.

Without the Fulfilment lambda invocation, I get the recognition result logged in the Unimrcp logs:

2022-01-10 12:49:36:306004 [INFO]   PostContentAsync: bot-name [acctNumLexVone] alias [Prod] user-id [ffeede28e2584e21] content-type [audio/lpcm; sample-rate=8000; sample-size-bits=16; channel-count=1; is-big-endian=false] accept [text/plain; charset=utf-8] request-attribs [{}] credentials-profile [default] <ffeede28e2584e21@lex>
2022-01-10 12:49:38:331879 [DEBUG]  Content Handler Called <ffeede28e2584e21@lex>
2022-01-10 12:49:38:331949 [INFO]   Process PostContent Results: transcript [two three nine nine one two five two three zero nine] intent [AcctNum] message [Your account number is eleven digits long, please tell me the number or say I don't have it.] content-type [text/plain; charset=utf-8] content [0] <ffeede28e2584e21@lex>

Is there anyway to see what Unimrcp plugin/server receives back from the AWS transaction?  From my Cloudwatch logs, I noticed that for the calls that was successful/working, the bot's dialog state appeared to be "dialogState": "ReadyForFulfillment".  Would the use of dialogAction of "Close" cause this dualogState to be changed to something else that Unimrcp is not expecting?

Kind regards,

Daniel

[Daniel Ng]

Dear all,

In case anyone else has encountered a similar issue, I've traced this problem down to:

1.) Lex bot expects that a message or a response card is supplied/triggered when the dialogState changes into Fulfilled.

As this message could either be set in the Lex bot or in the lambda fulfilment function, neither imposes any checks for it but during runtime it will cause the error and not return the transcription/recognition results.

To fix this, either set a default message/response card in either the Lex bot or associated lambda fulfilment function.

Kind regards,

Daniel