conversationState with StorageKey containing "[object Object]" when using conversation properties

[etiennellipse]

We are using the web adapter, and in order to pass along our User entity along the handlers inside the bot, we put it inside the conversation.properties which can contain custom properties, as documented here https://github.com/microsoft/botbuilder-js/blob/master/libraries/botframework-schema/src/index.ts#L146

So far, so good. Although I would like a simpler way of accessing my user entity all along the middlewares and handlers, but that is another story.

So my problem here is that when saving the conversationState, Botkit takes all the fields inside the conversation object and creates a key with them. See: https://github.com/howdyai/botkit/blob/master/packages/botkit/src/conversationState.ts#L27

My storage key looks like: websocket/conversations/7-[object Object]-7/

So, whenever the properties field is used, there will always be a [object Object] token in the key...

I think building the key this way can lead to some unpredictability, so I would suggest that the key should be built with specific fields in a way that, for example if I remove or add properties in between releases of my chatbot it won't break the conversation storage.

Context:

• Botkit version: 4.6
• Messaging Platform: Web
• Node version: v10.16.3
• Os: MacOS / Linux

[benbrown]

Ah! Interesting problem, and good point.

The reason we use all the keys is that some platforms (slack) take 4 or 5 pieces of info to properly define the conversation, and some only 1.

I don't really want to have to make the state driver platform-aware.

How about always excluding the properties field from the key?

On the other subject, you can theoretically pass any fields you want down the web adapter and they will end up in the resulting message object in your botkit app.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[etiennellipse]

Excluding the properties field can be a good solution!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[etiennellipse]

Not stale, still an issue.

[benbrown]

Fixed in the next release -> #1929