Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: Multiple responses per request #379

Closed
rwmb opened this issue Aug 28, 2018 · 5 comments
Closed

Bug: Multiple responses per request #379

rwmb opened this issue Aug 28, 2018 · 5 comments
Labels
bug Indicates an unexpected problem or an unintended behavior.

Comments

@rwmb
Copy link

rwmb commented Aug 28, 2018

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.

@Stevenic
Copy link
Contributor

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.

@rwmb
Copy link
Author

rwmb commented Aug 28, 2018

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.
capturar

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).

@rwmb
Copy link
Author

rwmb commented Aug 28, 2018

@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.

@rwmb
Copy link
Author

rwmb commented Aug 31, 2018

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.

@sgellock sgellock added the bug Indicates an unexpected problem or an unintended behavior. label Sep 5, 2018
@yochay
Copy link
Contributor

yochay commented Oct 30, 2018

This issue was moved to microsoft/BotBuilder-V3#44

@yochay yochay closed this as completed Oct 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or an unintended behavior.
Projects
None yet
Development

No branches or pull requests

4 participants