Node.js函数中DynamoDB GetItem调用异常及Intent无效问题排查

Hey there! Let's figure out why your Alexa skill's Lambda function is throwing that "Intent is invalid" error when you include the DynamoDB Key parameter, even though the standalone Lambda test works. Here's what's going on and how to fix it:

First, your error handling logic is missing critical safeguards #

Right now, when the DynamoDB getItem call fails (like if there's a permission issue, wrong key format, or table mismatch), you just log the error and still send a successful speech response to Alexa. That's a problem because:

• If the getItem call hits an error (e.g., missing permissions), the async operation might take longer than expected, causing your Lambda to timeout. Alexa interprets timed-out or malformed responses as an invalid intent.
• Even if it doesn't timeout, returning a "success" response when there's an underlying error can confuse Alexa's request processing pipeline.

Second, check your Lambda execution role permissions #

When you test the Lambda standalone, you're probably using a test event that leverages credentials with full DynamoDB access. But when Alexa triggers the Lambda, it uses the Lambda's assigned execution role. If that role doesn't have the dynamodb:GetItem permission for your mysk table, the getItem call will fail silently (only logged) and trigger the intent error.

Third, verify your DynamoDB parameter format #

You're using the low-level attribute format ("S": "la") for the Key. While this works for older AWS SDK versions, if you're using SDK v2 or later, you can use the simplified format (Key: { name: "la" }) which reduces typos. Also, double-check that the data type of your Key matches the table's primary key type (e.g., if your name key is a string, "S" is correct; if it's a number, you'd need "N").

Fixed Code Example #

Here's how to adjust your function to handle errors properly and use cleaner syntax (assuming SDK v2+):

function handleTestRequestQueen(intent, session, callback) { 
  var params = { 
    TableName: "mysk", 
    Key: { "name": "la" } // Simplified format for SDK v2+
  }; 
  
  ddb.getItem(params, function(err, data) { 
    if (err) {
      console.error("DynamoDB Error:", err, err.stack);
      // Send an error response to Alexa instead of a success message
      return callback(session.attributes, buildSpeechletResponseWithoutCard(
        "Sorry, I couldn't access the database right now.", 
        "", 
        ""
      ));
    }
    
    console.log("DynamoDB Response:", data);
    // Customize the response based on whether we found an item
    const responseText = data.Item ? `Found the item: ${data.Item.name}` : "I am the queen!!";
    callback(session.attributes, buildSpeechletResponseWithoutCard(responseText, "", "")); 
  }); 
}

Steps to Troubleshoot Further #

• Check CloudWatch Logs: Look at your Lambda's CloudWatch logs when triggered by Alexa. You'll see the exact error from DynamoDB (e.g., permission denied, invalid key type) which will point you to the root cause.
• Validate Lambda Role Permissions: Go to the IAM console, find your Lambda's execution role, and ensure it has a policy that allows dynamodb:GetItem on the mysk table.
• Test with Exact Parameters: Use the same Key value in your standalone Lambda test as you do in the Alexa skill to confirm consistency.

内容的提问来源于stack exchange，提问作者K.Pil