2

I'm starting with ASK development. I'm a little confused by some behavior and I would like to know how to debug errors from the "service simulator" console. How can I get more information on the The remote endpoint could not be called, or the response it returned was invalid. errors?

Here's my situation:

I have a skill and three Lambda functions (ARN:A, ARN:B, ARN:C). If I set the skill's endpoint to ARN:A and try to test it from the skill's service simulator, I get an error response: The remote endpoint could not be called, or the response it returned was invalid. I copy the lambda request, I head to the lambda console for ARN:A, I set the test even, paste the request from the service simulator, I test it and I get a perfectly fine ASK response. Then I head to the lambda console for ARN:B and I make a dummy handler that returns exactly the same response that ARN:A gave me from the console (literally copy and paste). I set my skill's endpoint to ARN:B, test it using the service simulator and I get the anticipated response (therefore, the response is well formatted) albeit static. I head to the lambda console again and copy and paste the code from ARN:A into a new ARN:C. Set the skill's endpoint to ARN:C and it works perfectly fine. Problem with ARN:C is that it doesn't have the proper permissions to persist data into DynamoDB (I'm still getting familiar with the system, not sure wether I can share an IAM role between different lambdas, I believe not). How can I figure out what's going on with ARN:A? Is that logged somewhere? I can't find any entry in cloudwatch/logs related to this particular lambda or for the skill.

Not sure if relevant, I'm using python for my lambda runtime, the code is (for now) inline on the web editor and I'm using boto3 for persisting to DynamoDB.

Josep Valls
  • 5,483
  • 2
  • 33
  • 67
  • FYI, I was able to properly setup the DynamoDB permissions for ARN:3 and everything is working fine with ARN:3, still failing for ARN:1 so I'm still interested in knowing how to debug/get more information in such cases. – Josep Valls Aug 11 '16 at 04:26

4 Answers4

3

tl;dr: The remote endpoint could not be called, or the response it returned was invalid. also means there may have been a timeout waiting for the endpoint.

I was able to narrow it down to a timeout. Seems like the Alexa service simulator (and the Alexa itself) is less tolerant to long responses than the lambda testing console. During development I had increased the timeout of ARN:1 to 30 seconds (whereas I believe the default is 3 seconds). The DynamoDB table used by ARN:1 has more data and it takes slightly longer to process than ARN:3 which has an almost empty table. As soon as I commented out some of the data loading stuff it was running slightly faster and the Alexa service simulator was working again. I can't find the time budget documented anywhere, I'm guessing 3 seconds? I most likely need to move to another backend, DynamoDB+Python on lambda is too slow for very trivial requests.

Josep Valls
  • 5,483
  • 2
  • 33
  • 67
  • 1
    I tried Lambda+Java+DynamoDB and couldn't make it work in the time budget. I thought it was 8 seconds, but for practical purposes, I really don't want my users having to wait for more than 3 seconds. For StarLanes I had to read at least two records, and write at least one. This sucked down about 2 seconds from the time budget. Because Lambda killed the JVM between calls, I couldn't cache or background thread anything. So I only use Lambda as a proxy now to a web service where I can do all the optimization I want. – Joseph Jaquinta Aug 11 '16 at 17:14
2

Unrelated to python, but I have found the same issue occurs for me if I do not have a handler for a specified intent:

  # lets pretend intentName is actually 'FooBarIntent'
  if (intentName == 'TestIntent') {
    handleTestRequest(intent, session, callback);
  } else {
    throw "Invalid intent"; 
  }

From here, amazon was barking that my lambda was invalid. For others it could indicate an error is being thrown earlier in the stack.

You can also log out your lambda errors with aws cloudwatch which will reveal any warnings or errors.

check out my repo, alexa lambda starter kit for a a simple hello world ask/lambda example.

random-forest-cat
  • 33,652
  • 11
  • 120
  • 99
1

I think the problem you having for ARN:1 is you probably didn't set a trigger to alexa skill in your lambda function.

Or it can be the alexa session timeout which is by default set to 8 seconds.

Dheeraj Suthar
  • 66
  • 7
  • 1
    Thanks. I already narrowed it down to the timeout problem, where did you get the 8 second timeout? I can change the deadline in the lambda function so it won't timeout but Alexa will still timeout. I feel that the value is slightly less than 8 seconds though and I set my timeout to 3 seconds just to be sure. – Josep Valls Aug 31 '16 at 13:53
0

My guess would be that you missed a step on setup. There's one where you have to set the "event source". IF you don't do that, I think you get that message.

But the debug options are limited. I wrote EchoSim (the original one on GitHub) before the service simulator was written and, although it is a bit out of date, it does a better job of giving diagnostics.

Lacking debug options, the best is to do what you've done. Partition and re-test. Do static replies until you can work out where the problem is.

Joseph Jaquinta
  • 2,118
  • 17
  • 15
  • Thanks for your answer, I'll definitely give EchoSim a look. Some debug options and more verbose messages would be great. – Josep Valls Aug 11 '16 at 16:55