我从ASK开发开始。我对一些行为有点困惑，我想知道如何从"服务模拟器"控制台调试错误。我怎样才能得到更多关于The remote endpoint could not be called, or the response it returned was invalid.错误的信息?
这是我的情况:
我有一个技能和三个Lambda函数(ARN: a, ARN:B, ARN:C)。如果我将技能的端点设置为ARN:A，并尝试从技能的服务模拟器测试它，我得到一个错误响应:The remote endpoint could not be called, or the response it returned was invalid.我复制lambda请求，转到lambda控制台的ARN:A，我设置测试，从服务模拟器粘贴请求，我测试它，我得到了一个完美的请求响应。然后，我转到ARN:B的lambda控制台，并创建一个虚拟处理程序，该处理程序返回与ARN: a从控制台给我的响应完全相同的响应(实际上是复制和粘贴)。我将技能的端点设置为ARN:B，使用服务模拟器对其进行测试，得到了预期的响应(因此，响应格式良好)，尽管是静态的。我再次前往lambda控制台，将代码从ARN:A复制并粘贴到新的ARN:C中。将技能的端点设置为ARN:C，它就可以正常工作了。ARN:C的问题是它没有适当的权限来将数据持久化到DynamoDB(我仍然熟悉系统，不确定我是否可以在不同的lambdas之间共享IAM角色，我相信不是)。我怎样才能知道ARN:A发生了什么?有记录吗?我在cloudwatch/log中找不到与此特定lambda或技能相关的任何条目。
不确定是否相关，我使用python为我的lambda运行时，代码(目前)内联在web编辑器上，我使用boto3用于持久到DynamoDB。
tl;dr: The remote endpoint could not be called, or the response it returned was invalid.也表示可能有超时等待端点。
我可以把它缩小到一个超时。似乎Alexa服务模拟器(和Alexa本身)对长响应的容忍度不如lambda测试控制台。在开发过程中，我将ARN的超时时间从1秒增加到30秒(而我认为默认值是3秒)。与ARN:3相比，ARN:1使用的DynamoDB表具有更多的数据，并且处理所需的时间略长，因为ARN:3的表几乎为空。当我注释掉一些数据加载的东西时，它运行得稍微快了一点，Alexa服务模拟器又开始工作了。我找不到时间预算，我猜是3秒吧?我很可能需要移动到另一个后端，lambda上的DynamoDB+Python对于非常琐碎的请求来说太慢了。
与python无关，但我发现如果我没有指定意图的处理程序，同样的问题也会发生在我身上:
# lets pretend intentName is actually 'FooBarIntent'
if (intentName == 'TestIntent') {
handleTestRequest(intent, session, callback);
} else {
throw "Invalid intent";
}
从这里，亚马逊叫我的lambda是无效的。对于其他人，它可能表明在堆栈中较早抛出了错误。
你也可以用aws cloudwatch注销你的lambda错误，这会显示任何警告或错误。
查看我的repo, alexa lambda入门工具包一个简单的hello world ask/lambda示例。
我认为你对ARN:1的问题是你可能没有在lambda函数中设置触发alexa技能。
或者它可以是alexa会话超时，默认设置为8秒。
我猜您在安装过程中错过了一个步骤。有一个你必须设置"事件源"。如果你不这样做，我想你会明白的。
但是调试选项是有限的。在服务模拟器编写之前，我编写了EchoSim (GitHub上的原始版本)，虽然它有点过时，但它在提供诊断方面做得更好。
如果没有调试选项，最好的办法就是做你已经做过的事情。分区并重新测试。执行静态回复，直到您可以找出问题所在。