qnabot-on-aws
qnabot-on-aws copied to clipboard
TypeError in Fulfillment lambda function after QnABot upgrade from version 3.x to 4.0.0
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.
A workaround for this issue is:
- Go to the settings in QnABot Content Designer
- Change the value of the variable
ENABLE_MULTI_LANGUAGE_SUPPORT
tofalse
and save the settings. - Change the value of the variable
ENABLE_MULTI_LANGUAGE_SUPPORT
back totrue
and save the settings again.
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!
I believe version 4.1.0 will also address this issue.