Bug: Multiple responses per request

[yochay]

From @rwmb on August 28, 2018 13:21

Botbuilder is sending multiple responses from the same request. When we send a message to the handler, it first sends a 202 (accepted) and then tries to send the response that the user requested (the handled message). This breaks the HTTP standard and prevents me from using botbuilder with Google Cloud Functions, because the first response stops the execution of the function (expected behavior). I've already created issues on firebase, google cloud platform, botframework and stack overflow, but as I imagined and as everyone suggested, the problem is the non-standard and unexpected behavior of the package.

Copied from original issue: microsoft/botbuilder-js#379

[yochay]

From @Stevenic on August 28, 2018 16:11

which version of botbuilder are you using? Version 4 or version 3? And can you tell me whats the code you're seeing for the second response (or even better where in the code is it being generated.) This shouldn't be happening.

[yochay]

From @rwmb on August 28, 2018 16:20

I'm using version 3.15.0
This is what happens when I try to make the requests the way botframework docs suggest.
After the 202 the function halts and the response to the user is never sent back.

By overriding the response object to prevent the 202 I was able to make the response work as expected, but this also makes the client that sent the message see a "Not sent" error for their message (incorrect behavior).

[yochay]

From @rwmb on August 28, 2018 16:30

@Stevenic regarding your other question, I don't see the second response, where the user gets his handled response, I assumed the 202 shouldn't be there since this is not necessary for the http request but apparently this is what microsoft chat clients (direct line, skype, etc) use to identify if the message was sent. Am I correct in this assumption?
If this is the case, then are all responses from the bot proactive? This doesn't make sense for me.

[yochay]

From @rwmb on August 31, 2018 12:12

I was able to make this work with Cloud Functions by intercepting the 202, creating a PubSub message to proactively send a response to the user and then manually sending back the 202, but there's a considerable delay between the user request and the response. I'll keep working on this but it all behaves as expected now, apart from the delay of course. From what I could understand, the current behavior of the package, without modifications, is to respond the user with a 202 and then send a proactively message to the user from the server after the http request has been resolved. Knowing this would have saved me a lot of time and headache.
Even though this behavior is unexpected for me, the only problem is that because Cloud Functions halt after a request has been resolved, this response never get's back to the user unless it's in the same(ish) execution cycle as the response, obviously not a possibility for me since I use multiple database/api/async calls to respond my user.
The real problem here then is the integration with Cloud Functions. Do you guys plan to target this or I should keep looking into solving this myself?
Thanks in advance.

[EricDahlvang]

This response behavior of the sdk is by design: https://github.com/Microsoft/BotBuilder-V3/blob/master/Node/core/lib/Session.js#L654

Some recent discussion about HTTP response characteristics can be found here: microsoft/botbuilder-dotnet#1009