A way to tell (not ask) without closing the session

[chesterm8]

It would make sense to have a way to tell the user something (as opposed to asking) without closing the session. There are situations when the session may contain useful contextual information that may be used by alexa in a further query, but that does not necessitate waiting for a response by default.

As an example use case:

• alexa, ask taxi app to book me a taxi
• I have booked you a taxi
• alexa, ask taxi app when that taxi will arive
• the taxi you booked will arrive in 10 minutes

I would be happy to create a pull request if a preferred approach can be identified - an alternate function with keyword (eg :tellWithSession)? another parameter to the ":tell" function?

[nstublen]

I would expect this kind of situation to be handled by referencing state that is stored outside of the session - in DynamoDB or some other form of persistent storage that can track the taxi request and lookup its progress in later sessions.

[chesterm8]

I feel that there is a space for using the session state provided by alexa to allow for that conversational style of interaction. Perhaps a better example would be

• Alexa, what is my most played song?
• Your most played song is 'Thriller'
• Alexa, what is my next most played song
• Your next most played song is 'Piano Man'
• Alexa, play that song.

You would not expect to be able to access 'Piano Man' outside the immediate context of that query, so persisting it in dynamodb (and having the overhead of setting up and maintaining that service) would seem to be overkill when there is a built in mechanism to handle it.

[nstublen]

You can just set the shouldEndSession flag to false to keep it active, just as you would when asking a question. This could be done by just using ":ask" instead of ":tell", but using a statement instead of a question.

Would that not work for some reason? I don't know if that violates any Alexa guidelines, though.

[GitTom]

I don't think it can be against the guidelines - the ask vs. tell distinction doesn't really exist beyond these implementations. All that matters is 'shouldEndSession' - there is nothing it needs to be consistent with.

If you want to keep the session open then just set shouldEndSession to false and you are done.

[chesterm8]

I understand how to achieve my goal using the raw alexa interface, I was just hoping to integrate it into this project in a nice way. Using ":ask" gives you a reprompt which is not desired. I will prepare a pull request with the kind of thing I am thinking of.

[chesterm8]

I raised two pull requests with different options - I prefer #36 , but #37 is also viable

[deegles]

Have you tried using :ask but not defining the reprompt text? It seems like that would accomplish what you're trying to do.

[chesterm8]

Having an empty reprompt text (as opposed to not setting it) effectively sets the value of 'reprompt' to the value of 'output', so alexa still stays listening (ring around the top of the echo stays lit), and she will repeat herself if you don't say anything to her.

[hyyan]

@deegles Any news about this issue , why @chesterm8 PR is not accepted yet ?

[ghost]

@hyyan @chesterm8 Thank you for the PR but both #36 and #37 are equivalent to emitting a :ask without a reprompt. You cannot persist a session across invocations, setting shouldEndSession to true will have Alexa wait roughly 8 seconds for an answer from the user. If nothing is said during those 8 seconds the session ends.

One thing you could try is having a dynamoDb table persist the session state. On subsequent invocations the state will be loaded from dynamo and it should support the use case described by @chesterm8.

I'm closing this for now. Feel free to re-open if you have further questions

[chesterm8]

I strongly disagree; as I have explained 'ask without reprompt' results in different behaviour compared to when using the code in my pull requests. The user experience is different enough that they are not equivalent options. At the moment the framework forces you to use DynamoDB to store state data when the Alexa API explicitly provides for this to be done without that extra hassle.

[ghost]

@chesterm8, could you provide more details on the different user experience?

The Alexa API will not persist the session state after the session has ended, and to show the session is ending, try modifying the code you use in your pull requests, add another intent handler named SessionEndedRequest (if it doesn't already exist).

'SessionEndedRequest' : function() {
    console.log(`Session ${this.event.session.sessionId} has ended with reason ${this.event.request.reason}`)
},

Now have your code emit a ':tell' with a shouldEndSession = false. You'll see that roughly 8 seconds after Alexa emits the outputSpeech you provided, the ring will turn off and your skill will receive a SessionEndedRequest with reason : EXCEEDED_MAX_REPROMPTS

I really appreciate your pull requests and your desire to make this SDK better 👍 but i'm afraid I don't understand what functionality it is adding.

[chesterm8]

@bclement-amazon Thanks so much for re-opening the issue and being willing to engage with me :) I do think there is a difference here; hopefully I can explain it well enough!

For arguments sake, lets say that we merged in Pull request #36 - that would mean that we can pass an extra boolean parameter to ':tell" calls to keep the session open. There are now 3 things we can do

tell and close session: The user asks a question, gets a response, alexa immediately goes back to listening. The session is closed, anything to be persisted has to be in DynamoDB.

tell and keep session open: The user asks a question, gets a response, alexa immediately goes back to listening. The session is kept open, the next request from that user (I assume this is timeboxed somehow) will have access to the session attributes.

ask with reprompt set to '' The user asks a question, gets a response, alexa waits to see if the user has a response. Once 8 seconds has elapsed a SessionEndedRequest is sent. At this point the session is closed, anything to be persisted has to be in DynamoDB.

I think that the ability to use option 2 is quite useful. It certainly would have been for me, and I can imagine a number of scenarios where that might be the case. For example an app where you can get a list of available sprockets, ask about them, and then buy one:

• Alexa, ask sprockets what is available Sprockets 1, 2 and 3 are available
• Alexa, ask sprockets about sprocket 3 Sprocket 3 is amazing and very good
• Alexa, ask sprockets to buy that sprocket Purchasing sprocket 3

The same kind of thing could be achieved by either using ':ask' or by storing the session state in DynamoDB. Adding in DynamoDB to store this state when alexa provides a mechanism itself seems like an unnecessary burden on the dev. Using ':ask' requires the user to respond immediately (within 8 seconds), and requires the response from alexa to suggest what action should be taken.

[nstublen]

With your changes in place, using ':tell' as you propose, and leaving the session open, don't you see the same 8 second time limit that you see with ':ask'?

I understand (I think) your desire to keep the session open even without wanting Alexa to prompt with a question, but I don't think you're going to get any different functionality than what you get with ':ask', which leaves you with simply using ':ask' without phrasing Alexa's response as a question.

[phlemoine]

FWIW, the tell and keep session open scenario may prevent the skill certification to pass. The user must be clearly asked to engage in the conversation. While technically possible, this scenario may not be recommended.

On Mar 23, 2017 10:17 AM, "Neal Stublen" notifications@github.com wrote:

With your changes in place, using ':tell' as you propose, and leaving the session open, don't you see the same 8 second time limit that you see with ':ask'?

I understand (I think) your desire to keep the session open even without wanting Alexa to prompt with a question, but I don't think you're going to get any different functionality than what you get with ':ask', which leaves you with simply using ':ask' without phrasing Alexa's response as a question.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/alexa/alexa-skills-kit-sdk-for-nodejs/issues/35#issuecomment-288793826, or mute the thread https://github.com/notifications/unsubscribe-auth/ATZ3zOnCrQUWNT1pDkTUmnMRiXUAt6Akks5roqkmgaJpZM4K4_YZ .

[chesterm8]

@nstublen I don't see the same 8 second limit - I can see attributes over 3 (update - 17) minutes after the previous request when using the 'tell and keep session open' scenario. @phlemoine I have not submitted my app for certification and so am not sure about this, however enabling the session to exist for longer than the 8 second :ask window allows for the user to think and/or consult with someone/something before taking their next action.

[cspinillo]

phelomine is right. Your app won't pass.

The best way to do this would be with a Dynamo DB and a progress state within it.

THe example you gave above really doesn't need to maintain state, however. Your utterances could handle all of that regardless of if state is current. Asking about sprocket 3 isn't dependent on a session, or at least, nothing above suggests that it should be. I would simply wrap up the ask to buy it into the second utterance.

i.e. " Sprocket 3 is amazing. Would you like to purchase it? " that fits into the ask emit and will allow you to persist session at that point.

[dipesh-gandhi]

Somewhat related to this topic.. I'm using dynamo to persist session data by invoking emit :saveState. Although, I'm not sure how to query dynamo db for next session using this sdk. Wasn't able to locate in docs.

[chesterm8]

Ok sure, if this method of using the state is not acceptable to the alexa 'way of working' then I guess there is no point in modifying the SDK to allow it. Thank you all for your engagement with me on this 😄

[eightsixeight]

reopening an old problem but this is still a bad issue.

if you use ask: to keep session open, then you need to have an exit utter to end this to be certified, but exit crashes always on unhandled.