How to Debug Errors for Custom Alexa Skills
While building an Alexa skill, you may run into issues when Alexa says, “There was a problem with the requested skill’s response” (for the dev version of the skill) or, “Sorry, I’m having trouble accessing your skill right now” (for the live version of the skill). This can happen due to a variety of reasons, including:
- Invalid SSML – A tag might be missing or not properly closed.
- Invalid audio files used – An mp3 file may be invalid. See requirements for audio files here.
- Issues with assets used by the skill – Maybe the skill uses image files that are corrupt or missing.
In such cases, when there is an error, the session is closed and the skill receives the SessionEndedRequest. Developers can use this request to log, debug, and identify the reason for the error to fix the issue. As pointed out in this blog post, developers can also log additional information such as the Request Id and Intent Name. You can use this information, along with the error information from the SessionEndedRequest, to identify the failing intent as well as the root cause of the failure.
The SessionEndedRequest returned in case of an error contains the error type and the error message and looks something like this:
{
"type": "SessionEndedRequest",
"requestId": "amzn1.echo-api.request.33504577-0a64-4292-b733-1f7f5ab53161",
"timestamp": "2019-03-03T17:16:19Z",
"locale": "en-US",
"reason": "ERROR",
"error": {
"type": "INVALID_RESPONSE",
"message": "Invalid SSML Output Speech for requestId amzn1.echo-api.request.448ddb45-d25e-42d4-b9d0-4cbbac291c82. Error: Invalid SSML element prodody"
}
}In Java, you can obtain the error information from the handle method of the SessionEndedRequestHandler as shown below:
public class SessionEndedRequestHandler implements RequestHandler {
@Override
public boolean canHandle(HandlerInput input) {
return input.matches(requestType(SessionEndedRequest.class));
}
@Override
public Optional<Response> handle(HandlerInput input) {
SessionEndedRequest request = (SessionEndedRequest) input.getRequestEnvelope().getRequest();
if(null!=request.getError()) {
System.out.println("Error Message: "+request.getError().getMessage());
}
return input.getResponseBuilder().build();
}
}In Node, we can obtain the error information as follows:
const SessionEndedRequestHandler = {
canHandle(handlerInput) {
return handlerInput.requestEnvelope.request.type === 'SessionEndedRequest';
},
handle(handlerInput) {
if(null!=handlerInput.requestEnvelope.request.error) {
console.log(JSON.stringify(handlerInput.requestEnvelope.request.error));
}
return handlerInput.responseBuilder.getResponse();
},
};Once we have this information logged, we can check our logs to debug and identify any issues.
The example below shows how I can see the error information that I logged using the technique described above. In this example, I’m also logging the request ID and the intent, which is why when I lookup that request ID (which is for the error case) in Amazon CloudWatch logs for my skill, I am able to see the intent that is failing along with the reason for the failure.
Using this information in the logs, I can identify that the reason for the error (i.e. Alexa responded “There was a problem with the requested skill’s response” or “Sorry, I’m having trouble accessing your skill right now”) was that in my ‘CapitalIntent’ my SSML is malformed and I am missing the ‘</prosody>’ closing tag. Thus, I can go back in my code and identify the SSML outputSpeech in my handler (CapitalIntentHandler in this case) and fix it.
Not identifying and addressing such issues with the skill may result in a poor and inconsistent customer experience, which could impact skill reviews.
You can also use custom monitoring to identify spike in such errors. This way, you can receive an alertif there are errors being returned for a certain intent. For example, if someone accidentally uploaded an invalid mp3 file that is used in the skill’s response, this will result in errors that you’ll want to identify and address.
Developers should also include automated testing as part of their CI/CD framework so that they are able to identify issues with the skill. The Skill Management API (SMAPI) also allows developers to test their live skills programmatically using the Simulation and Invocation APIs that help create automated tests that can identify bugs and regressions. You can perform end-to-end testing with these APIs to ensure that your skill is functioning as expected.
Related Content
For more guidance on skill debugging and testing, check out the following resources: