conv.data (session data) rots on long sessions of actions.intent.MEDIA_STATUS

[hyzhak]

I occasionally get empty object in conv.data (session data) for actions.intent.MEDIA_STATUS intent.

This bug isn't easy to reproduce but in long sessions, about an hour or more of media responses, I get empty conv.data (session data), which we use heavily and it shouldn't be empty. Because we store playlist there, we lost context with empty session data.

It seems like conv.data rots maybe because actions.intent.MEDIA_STATUS intents there could be few minutes without any interaction with user.

What is interesting conversation is still active:

{
  //...
  request: {
  conversation: { 
    conversationId: 'ABwpp....',
    type: 'ACTIVE',
    conversationToken: '["_actions_on_google"]' 
  }
  //...
}

[Fleker]

Can you try moving to conv.user.storage? I'll file a bug about the expiration of session data. There may be a hard timeout.

[igilham]

Google has confirmed that conv.data only persists for what they call a session, which is a single response-request-response interaction. You set the data in the first request, then you expect to receive it back in the second. If the second request does not modify it, you get nothing in the third request.

To preserve the everything stored in conv.data it is necessary to modify it on every request to your action. This can be achieved in a middleware that increments an interaction counter or adds a timestamp etc.

[hyzhak]

@igilham oh, very interesting, I haven't seen such problem, but in my case conv.data changes all the time. And there is no way to get the same conv.data, so problem with some inner "timeout/expiration".

[igilham]

That sounds like a different issue. I've not tested it hard enough to come across that one so far.

[hyzhak]

@igilham for the moment I decided to spin FireStore to store user's session. There is other problem - I would need to sweep expired sessions after awhile. But it is job for cron or something similar

[igilham]

That'll work. I believe you'll need user consent to store data before that'll pass certification though.

Also there's conv.user.userStorage or similar for that.

[Fleker]

Yeah you'd be able to store the timestamp for a session within Firestore, then create a cloud function connected to Cloud Scheduler to clear out old entries.

[hyzhak]

@Fleker I hit another problem by using conv.user.userStorage https://developers.google.com/actions/assistant/save-data#save_data_across_conversations it force us to Obtaining consent prior to accessing userStorage from user. Which we don't want to ask user - because it makes action unavailable for people which doesn't use VoiceMatching. I continue use firestore to store user's session. But how could I persistently identify user's session, or maybe device?

I see we have conv.request.conversation.conversationId (undocumented) but I'm not sure how long it will stay here, and whether I can rely on it for a while

[igilham]

I think the Assistant platform needs a conversation ID to associate conv.data to a conversation, but I get the impression that Google wants to make their platform more opaque so that developers don't have to worry about the details of too many identifiers.

Unfortunately their implementation is currently a little buggy and the project doesn't seem to have much support, documentation or any full-time developers. I hope they can improve their communication and responsiveness to problems as more customers start trying to build actions on the platform.