Announcement: The Alexa Skills Community Is Moving To Stack Overflow

For improved usability and experience, Alexa skills related forum support will be transitioned to Stack Overflow. Effective January 10, 2024, the Amazon Developer Forums will no longer be available. For continued Alexa skills support you can reach out to us on Stack Overflow or via Contact Us.


r-j-b avatar image
r-j-b asked

SessionEndedRequest throws an error - how can I solve this?


I have a problem with the SessionEndedRequest - it actually is not working at all. Whenever the user says exit I get the following Alexa error: "There was a problem with the requested skill's response".

I am using the basic code from any SDK2 example and haven't changed a thing. In other skills this is working, but here it throws an error. This is the code:

const SessionEndedRequestHandler = {
  canHandle(handlerInput) {
    const request = handlerInput.requestEnvelope.request;
    return request.type === 'SessionEndedRequest';
  handle(handlerInput) {
    const { requestEnvelope } = handlerInput;
    const request = requestEnvelope.request;
    console.log(`Session ended with reason: ${request.reason}: ${request.error.type}, ${request.error.message}`);
    console.log(`Session ended with reason: ${handlerInput.requestEnvelope.request.reason}`);

    return handlerInput.responseBuilder

The JSON input says:

"request": {
	"type": "SessionEndedRequest",
	"requestId": "amzn1.echo-api.request.02d0fba2-babf-4ec8-8774-84d9e1e604a9",
	"timestamp": "2018-11-22T14:01:11Z",
	"locale": "en-US",
	"reason": "USER_INITIATED"

The JSON output says:


In CloudWatch the error is:

2018-11-22T13:53:53.198Z	0c132d53-ee5e-11e8-a8c9-096dbaf7d85a{
    "errorMessage": "Cannot read property 'name' of undefined",
    "errorType": "TypeError",
    "stackTrace": [
        "Object.canHandle (/var/task/index.js:266:54)",
        "DefaultRequestMapper.<anonymous> (/var/task/node_modules/ask-sdk-core/lib/dispatcher/request/mapper/DefaultRequestMapper.js:74:61)",
        "step (/var/task/node_modules/ask-sdk-core/lib/dispatcher/request/mapper/DefaultRequestMapper.js:44:23)",
        " (/var/task/node_modules/ask-sdk-core/lib/dispatcher/request/mapper/DefaultRequestMapper.js:25:53)",
        "fulfilled (/var/task/node_modules/ask-sdk-core/lib/dispatcher/request/mapper/DefaultRequestMapper.js:16:58)",

I have no idea what's going on here.

Thanks for reading so far. I know this might all just be basic, but I am still learning.


alexa skills kitalexalambdaintentsnodejs
10 |5000

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Rokas avatar image Rokas commented ·

It seems that it hits handler or something, before going to session ended request. There it tries to access 'name' property and fails. Can you look in your code for places where you try to access 'name' and share them?

0 Likes 0 ·
r-j-b avatar image r-j-b Rokas commented ·

I have a couple of variables called SKILL_NAME. The only other place where 'name' is used is in canHandle in other handlers:

But this one is not used in the SessionEndedRequest (see code above).

The interesting thing is that the exact SessionEndedRequest code is used in other skills and works perfectly fine.

0 Likes 0 ·
Rokas avatar image Rokas r-j-b commented ·

Every time you use some sort of utterance, in the backend it goes through all of the handler can handle functions in a sequence you registered them. So let's say if you register handler which canHandle function always return true as first one, it will always get invoked no matter what utterance you'll use.

So in your case, session ended request doesn't have property, but it still has to go through all of the can handle conditions, to find the right handler. Because it hits one of the canHandle function which tries to check it, it fails. To avoid this, structure your can handle functions better. First I always check what typo of intent it is. Then I check the name:

return handlerInput.requestEnvelope.request.type === 'IntentRequest'
  && === 'AMAZON.HelpIntent'

If you structure your canHandle this way, when sessionEndedRequest comes (its type is 'SessionEndedRequest'), it will short the check on the first condition and second condition won't be checked and this will allow you to avoid the error you are getting. But do this only for other can handle, don't touch session ended request, because it looks correct.

0 Likes 0 ·
Show more comments

0 Answers