-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Web Chat shows retry but message is really sent to bot #465
Comments
I am having the same issue. My bot is doing image analysis so it could take up to 10 seconds to respond. |
Yeah! And also, if we open the same web chat in 2 tabs lets say the bot is
present over a website it will throw 412 precondition failed. Which again
breaks the conversation.
…On 20-May-2017 12:28 AM, "forceamp" ***@***.***> wrote:
I am having the same issue. My bot is doing image analysis so it could
take up to 10 seconds to respond.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#465 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIyDm79hH3OvMvJuYGCVya15Jrs5aOsLks5r7eZBgaJpZM4NdbiG>
.
|
Other channels allow 15 seconds to respond. It would be nice if webchat abided this timeout too. |
How quickly is "retry" shown? Which SDK are you using? DirectLineJS (which is what WebChat uses) actually observes a 20 second timeout. If it's showing "retry" before then, it's because of a different problem. |
@alokraj68 I don't quite understand your scenario but it sounds like a different bug. Please open a new issue for it. |
I am also facing the same issue, the bot responds with "couldn't send retry" but actually the conversation proceeds. How can i fix this? |
We fixed this by immediately returning from the message controller with HttpOK. And start the bot in a async void background thread.
From: Akash Ranjan
Sent: Tuesday, June 27, 2017 2:30 AM
To: Microsoft/BotFramework-WebChat
Cc: ohmusama; Comment
Subject: Re: [Microsoft/BotFramework-WebChat] Web chat shows retry but messageis really send to bot (#465)
I am also facing the same issue, the bot responds with "couldn't send retry" but actually the conversation proceeds. How can i fix this?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I would still like to know more about this problem. WebChat/DirectLineJS has a 20 second timeout. Are you all seeing faster fails than that? If so it's (probably) not on the client side. In your response please say which SDK you are using (.net or node). |
In telemetry we were seeing intermittent 15s timeouts, but it appeared to the client faster on occasion. We assumed it was our fault.
From: Bill Barnes
Sent: Tuesday, June 27, 2017 9:04 AM
To: Microsoft/BotFramework-WebChat
Cc: ohmusama; Comment
Subject: Re: [Microsoft/BotFramework-WebChat] Web chat shows retry but messageis really send to bot (#465)
I would still like to know more about this problem. WebChat/DirectLineJS has a 20 second timeout. Are you all seeing faster fails than that? If so it's (probably) not on the client side.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Hi guys, |
I am using rest api on python, maybe the case is of timeout but how can i handle it if the processing work takes more than 20 sec? |
but in our case, the processing is not taking that long when we do the testing, |
I'm having the same issue with the built in iframe.
|
Hello everyone, here's a couple of tips for these kinds of errors.
|
Hello every once i am working on microsoft bot, direct line, POST https://webchat.botframework.com/v3/directline/conversations/HyZVX4cBPGh115QwKfStKj/activities 502 (Bad Gateway) this is in channel page: |
…ove-depricated-fields #22733 - removed fields designed for just a single bot
Is there ways to customize when the retry message comes up? Some OCR processes take more time than the default 20 seconds. |
Investigate if fixed in v4. If not, mark as P3 or P4 for 4.4 |
This is not an issue with WebChat. There are a number of things that can cause a 'couldn't send retry'. Generally, not returning HttpStatusCode.OK from the bot within 15 seconds is the primary cause. Returning some other status code (or not returning any status code), a long running process within the bot, a fatal exception within the bot, cold start issues (solved with 'Always On' in Azure), etc. There is not a single resolution for this, and it is definitely not a WebChat issue. If 'couldn't send retry' is displayed when in fact the message did arrive, it is an indication there is a problem within the bot code. |
@EricDahlvang : the issue stated is that the 'couldn't send retry' is raised even if the message i received by the bot. If you try with a long running operation (even a Thread.Sleep) you always receive 'couldn't send retry', but the message is received by the bot code. What we do not understand from @compulim is if the typing Activity sent every 3 sec should get rid of 'couldn't send retry' or is just an usability/estetic workaround for the user. We are able to send the typing activity during long running operations, but we alway get the retry even if we process the original message back to the user. thanks |
@adalfa Sending a typing activity will not result in also responding with HttpStatusCode.Ok within the required 15 seconds. The connector service will hold the connection open for 15 seconds (even if the message has been received and is being processed bot side). It holds the connection open until it receives an HttpStatusCode.Ok (200). If it does not receive the 200, it assumes the message was not successfully sent and this propagates back to the WebChat control, showing as 'couldn't send retry'. This is how the protocol is setup. This is not related to WebChat, but rather the behavior of the connector services communication with the bot. If your bot is not responding with a 200 within 15 seconds, it is a bot issue. Edit: see here for more discussion around this microsoft/botbuilder-dotnet#598 |
@EricDahlvang thanks for the response. I understand that we are talking of a sort of violation from the bot code to the connector. what I fail to understand is @compulim suggestion
your statement make me think that this is not a viable resolution from the bot side so I ask you what is expected in 4.4 version: an update to the documentation or any change to the webchat code or anything else? |
I'm not sure why @compulim suggested that. He is out today. It is fine to continue the discussion here, I'm just trying to clear up any confusion about why developers see 'couldn't send retry' in WebChat when in fact the message was received by the bot. Future developers who come across this issue should be aware of how the underlying protocol works. |
I'm leaving this issue open since it appears to be a common question Web Chat users have. However there is no action item for the Web Chat team. If you would like to pursue more information or track the potential change in protocol, please see microsoft/botbuilder-dotnet#598 |
Sorry didn't response to this sooner. @adalfa if the bot is expected to take > 15 seconds to work on one thing, I believe the best practice is the bot respond to it first (by sending typing indicator, or just do nothing). Then, the bot should use proactive messaging mechanism to send result back later. That's why I was saying, "the bot replied, Web Chat will not receive 502". What do you think? |
Hi @compulim, The issue is there even after typing indicator is working. "botbuilder-ai": "^4.9.0", Botframework v4, Typescript. Webchat How to fix this? Please let me know if any more information is required. |
Botframework-webchat 4.9.1 I have a similar problem. I think this was a problem with the library itself because I tried it on Bot emulator and it works just fine. But I just found out why it does happen for instance if we have a similar case here. This problem will happen if you're calling the action type DIRECT_LINE/POST_ACTIVITY_FULFILLED like this way. if(action.type === "DIRECT_LINE/POST_ACTIVITY_FULFILLED" && action.payload!.activity!.entities!.length > 0){
//code here...
} The non-null assertion operator just won't work instead when I changed it to operational chaining the problem was solve. if(action.type === "DIRECT_LINE/POST_ACTIVITY_FULFILLED" && action.payload?.activity?.entities?.length > 0){
//code here...
} Or the longer way. if(action.type === "DIRECT_LINE/POST_ACTIVITY_FULFILLED" && action.payload && action.payload.activity && action.payload.activity.entities && action.payload.activity.entities.length > 0){
//code here...
} @compulim do you have any idea why the already sent message got called again when there's a new request? |
Emulator is using Web Chat UI without much customization. 😅 However, Emulator emulates Azure Bot Services (i.e. the Direct Line protocol), thus, the actual activity being sent to the bot could be slightly different, due to the emulation layer. Direct Line protocol diagram can be found here, https://github.com/microsoft/BotFramework-WebChat/blob/master/docs/media/direct-line-sequence-diagram.png. Web Chat consider a message is being sent successfully, when the bot acknowledged it (a.k.a. read receipt). To consider the message is being successfully sent, technically, it means 2 bottommost packets (blue and orange), need to be received on the Web Chat side in a positive manner. If the bot crashed in the midway, the purple packet (from bot to ABS) will not be sent. Thus, it will lead to the orange packet missing. From your code, can you check if the bot crashed? Also, please look at your browser's network tab (or Fiddler) to check if the traffic is correctly received on one end. |
Hi @compulim, The screenshot i have given, it was from my web page. In the emulator i was not getting the issue. Now i did some UI modification for the bot and the issue is solved automatically. Warm Regards, |
@compulim, Oh thank you for that explanation. |
@compulim, Yea my bad. |
Hi,
The web chat is showing could not send please retry, but the message is really sent to bot. what really goes wrong is that user will press retry and the bot will get the message every time the retry is pressed.
The text was updated successfully, but these errors were encountered: