qnabot-on-aws icon indicating copy to clipboard operation
qnabot-on-aws copied to clipboard

TypeError in Fulfillment lambda function after QnABot upgrade from version 3.x to 4.0.0

Open sebstern opened this issue 4 years ago • 3 comments

I've upgraded an existing installation of QnABot version 3.x to version 4.0.0 following the instructions in this blogpost. CloudFormation did not report errors during the stack update.

After the upgrade QnABot could no longer answer any question.

In CloudWatch Logs the following type error in the Fulfillment Lambda function was logged

{
    "errorType": "TypeError",
    "errorMessage": "_.get(...).toLowerCase is not a function",
    "stack": [
        "TypeError: _.get(...).toLowerCase is not a function",
        "    at Array.parse (/var/task/lib/middleware/1_parse.js:96:67)"
    ]
}

which lead to the if-statement

if (_.get(settings, 'ENABLE_MULTI_LANGUAGE_SUPPORT', "false").toLowerCase() === "true"){
//
}

in the "parse" middleware where apparently

_.get(settings, 'ENABLE_MULTI_LANGUAGE_SUPPORT', "false")

in the condition did not return a string.

I have enabled multi-language support in AWS Systems Manager Parameter Store following some documentation I've found a couple of month earlier.

sebstern avatar Jun 22 '20 15:06 sebstern

A workaround for this issue is:

  1. Go to the settings in QnABot Content Designer
  2. Change the value of the variable ENABLE_MULTI_LANGUAGE_SUPPORT to false and save the settings.
  3. Change the value of the variable ENABLE_MULTI_LANGUAGE_SUPPORT back to true and save the settings again.

sebstern avatar Jun 22 '20 15:06 sebstern

Thanks @sebstern ! When we introduced the Content Designer Settings UI in 3.x, setting that were previously saves as boolean values in parameter store became string values. We updated our code to expect them as string values, but neglected to consider an upgrade scenario where the custom setting was previously stored as a boolean directly in parameter store, rather than as a string saved by the Content Designer settings page.
Toggling the setting to false, and back to true, is the right workaround - for ENABLE_MULTI_LANGUAGE_SUPPORT, or for any other true/false setting that was customized directly in parameter store in a previous release. We will try to get a more robust fix for this issue into the next release. Thanks again!

rstrahan avatar Jun 22 '20 16:06 rstrahan

I believe version 4.1.0 will also address this issue.

bobpskier avatar Jul 24 '20 04:07 bobpskier