Calls to the createConversation return wrong payload type, invalid payload data

[benbrown]

Version

4.7.0-111757

Describe the bug

When calling the createConversation API, such as here in the core Bot Framework Adapter, the Emulator responds with an incorrect payload.

Whereas the code expects the payload to include the new conversation id in the id field, emulator returns it in the conversationId field.

In addition, if the value returned in conversationId IS used to send messages, they do not appear in Emulator.

To Reproduce

Use the adapter.createConversation() method. The expectation is this will create a new conversation that includes the bot and the user. (Usually this means a 1:1 private message in Teams.) This is used in many proactive scenarios.

Expected behavior

1. Expect the emulator to return a valid conversation id in the id field of the payload
2. Expect the conversation id to be usable - either to result in messages appearing in the same chat tab OR preferably open a new tab automatically to contain the newly created conversation.

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

[bug]

[benbrown]

Related to howdyai/botkit#1834

[tonyanziano]

The payload shape can easily be changed, however, making it so that the Emulator will show the correct UI when sending messages with the supplied conversation ID is not trivial.

The Emulator controls the flow of creating a conversation most of the time -- this case being an exception -- and so there is some heavy lifting done client-side that sets up the redux store to properly display the UI for the new conversation in addition to telling the Emulator's backend (channel) to create a record for the new conversation.

When you just hit the create conversation endpoint, the Emulator is just creating the conversation record and not performing the other half of the work so the UI will not behave the way it usually does and display a tab for the conversation.

---

This was a side effect of the work done in #2034 . At the time I was unaware of any scenario in which an external source would be starting the conversation and so setting up the new conversation flow this way didn't seem problematic.

[cwhitten]

R9 commitment:

Expect the emulator to return a valid conversation id in the id field of the payload

We'll fix this. For:

Expect the conversation id to be usable - either to result in messages appearing in the same chat tab OR preferably open a new tab automatically to contain the newly created conversation.

This will be a larger undertaking and we will scope & prioritize.

[cwhitten]

The R9 commitment was addressed. We'll close this and tackle the larger effort in a separate work item.