v3.5.29 critical bug: won't connect to local bot

[longsoft-dev]

v3.5.27 was all good then auto updated to v3.5.28 then a few minutes later to v3.5.29
The v3.5.29 cannot connect to local bot. Clicking the connect, nothing happened, like dead. No error messages or logging at all.

[longsoft-dev]

revert to v3.5.27 for the moment as that version was working without any problem.

[Jeffders]

Are you using ngrok? What URL are you using to connect to the bot? Are you using an MS App ID and password with the locally hosted bot?

Presumably you are (1) opening the emulator, (2) entering the URL and credentials (if any), and (3) pressing connect, right?

I've not experienced the issue you are reporting, but let's try to figure out what's going on here.

[longsoft-dev]

Not using ngrok. URL is http://localhost:3978/api/messages. Yes locally hosted bot with blank MS App ID and password as this is allowed in v3.5.27. Is AppID and password mandatory in v3.5.29? Yes 1 2 3, except in step 2, don't have to manually enter URL because it's in the drop list.

[stenoid]

I've had a similar issue. I don't use ngrok and just connect with localhost (I do specify the app id and password, but this never seems to come through as expected so I also embed a separate id in the url to get round this issue). I'm seeing the requests coming through in node.js, but no responses appear in the emulator. I downgraded to v3.5.27 and it started working again.

[ghost]

Experiencing the same issue. All configuration is the same between the upgrade v3.5.27 to v3.5.29. Bots are built using v3.8.0/.1 of the botbuilder npm package.

[ghost]

FYI, it looks like the latest source has change,

May 10, 2017 at 2:08:46 PM PDT
b71cd1a Upgrading typescipt version to 2.2.2 to support latest DirectLine package

App running locally from built source at this commit doesn't have the issue.

[longsoft-dev]

Found a work-around: firing up fiddler resuscitates the emulator...

[eanders-ms]

@beatgates That's in interesting piece of information, thanks. Is it still broken when fiddler isn't running?

[longsoft-dev]

Yes, it's still broken if fiddler isn't running. Guess those people who can use this version are not behind a corporate proxy/firewall or using a .Net bot? Still it doesn't make sense for the emulator not connecting to local hosted NodeJS bot...

…

On 18/05/2017 14:50, Eric Anderson wrote: @beatgates <https://github.com/beatgates> That's in interesting piece of information, thanks. Is it still broken when fiddler isn't running? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#187 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASdC7SfLWpgTYwGFDNXaz-Sl6dLig9xks5r684CgaJpZM4NWJ6V>.

[stenoid]

Yes, that matches my experience. The emulator auto-updated back to 3.5.29, but because I was working from home it started working again. Back in today (behind the proxy/firewall) and it stopped working.

[ghost]

See my comment above. FWIW the emulator works for me when built from the latest master source.

Could this be the reason?

May 10, 2017 at 2:08:46 PM PDT
b71cd1a Upgrading typescipt version to 2.2.2 to support latest DirectLine package

[MarcoScabbiolo]

Having the same issue behind a corporate proxy with 3.5.29, version 3.5.27 is working. Haven´t and wont try with Fiddler. Disabling the local machine firewall and antivirus protection doesn't change anything. Although my network is behind a perimeter firewall, that shouldn't be a problem unless the emulator is trying to connect to the internet.

Win 10 64 bits, using localhost, and the PC is configured to avoid the proxy for localhost so the error is even more strange.

I´m free to help with troubleshooting, just give me some instructions on how to enable logging and/or where to find the logs.

[eanders-ms]

@MarcoScabbiolo would you be willing to build the emulator locally from source? If you can repro with a local build, then I can push code changes to you until we've solved the problem. The difficulty here is we don't have a local repro.

[MarcoScabbiolo]

@eanders-ms Totally understand that, next week I might have some time to do a local debug and in the best case scenario make the pull-request. I'll let you know.

[MarcoScabbiolo]

So here is what's going on:

DirectLine internally makes a call to http://127.0.0.1:57142/v3/directline/conversations which fails if, for example, you're behind a corporate proxy. No visual feedback is shown in the application when this error occurs. These are the error details:

{
   "message":"ajax error 503",
   "xhr":{

   },
   "request":{
      "async":true,
      "crossDomain":false,
      "withCredentials":false,
      "headers":{
         "Accept":"application/json",
         "Authorization":"Bearer eiik9jn9mijfmkem7c",
         "X-Requested-With":"XMLHttpRequest"
      },
      "method":"POST",
      "responseType":"json",
      "timeout":20000,
      "url":"http://127.0.0.1:57142/v3/directline/conversations"
   },
   "status":503
}

I've managed to solve the problem by bypassing the proxy for requests to the IP 127.0.01. To reproduce
the error you could block requests to that IP.

[cwhitten]

Closing as stale.