I have multiple agents created with Dialogflow and many of them are live in Production. However, suddenly the Dialogflow projects disappeared and now I see only the option to create a new agent.
However, I see that Production Agents are working fine. I verified it through the app that I created which is connected to Dialogflow API.
The google cloud status dashboard is reporting that the problem has been solved. I checked my agents and they came back.
Same happened to me today, then I accessed after some time and they were back, but when I tried to work on an agent after a bit it gave error and all the agents disappeared again. I think they may be having server issues?
I just created a new Agent and the agent that disappeared came back.
please follow GCP status page for more info status.cloud.google.com
Situation 1
I wrote my own bot framework and deploy to Azure,
the Test in Web Chat shown me "Waiting for bot to be ready after deployment".
Situation 2
I downloaded the source code from Azure bot Services,after that I deploy back to Azure, the Web Chat shown me "Waiting for bot to be ready after deployment".
I also faced this issue and this is how I solved it.
Changed my publish settings to have Remove additional files at destination checked. This is an important step because when you provisioned a new web app bot, it will already have some files in the location. So when you publish your code, it will be placed along with the code files which already exists. You can also test it by navigating to the /api/messages url. If this gives you error, then this is most likely the case.
I also updated all the NuGet dependencies.
The other thing that caused me a bit of issue was the App Password. The app password in your web.config should match the one which is already generated for your BOT. Do not create a new password from the bot management page. If you did that then make sure that you change/update the password in web app bot application settings and also in the web.config file. When you host the bot, by default it will use the Application Id and Application Password which were generated automatically. You can see these values in the Web App Bot service type which is under the section App Service Settings>Application Settings. Scroll down to the bottom and you will see these two settings. Copy the values of Application Id and Application Password and update them in the Web.config file.
Hope this help!
What fixed it for me was changing Destination URL in Publish Settings to https. For some reason default is http.
I had missing node packages that I wasn't aware of. I found the errors in the output logs at https://[bot-name-here].scm.azurewebsites.net/dev/wwwroot/:vs.output
Or you can Navigate to this by going to Build -> Click 'Show output' (or Shift+Command+U) (its the 5th icon in the left hand side menu on the Build window)
Hope that helps!
Some ideas to troubleshoot for people having the same error:
Check that the server hosting your bot is actually running. If https://YOUR_BOT.azurewebsites.net is timing out, then your server is not running, check your config
Check if you have logs in the App Service: Enable everything under App Service > Diagnostic logs, then go to App Service > Log Stream.
Check potential errors under Web App Bot > Channels > Web Chat > Issues
Check that the files on the server look ok by going to App Service > App Service Editor (Preview)
Close all your browsers, especially if they have been running for a long time and/or you have been changing a lot of config/files recently
I fixed the issue by using a combination of those points
I had the window open for a few days, and "Test in Web Chat" would just show "Waiting for bot to be ready" and the juggling progress indicator, forever. I duplicated the tab and it came right up. I think my session may have expired or something, because any new, duplicated tab, I could bring the bot up in just fine.
I solved the problem by, in Visual Studio's Solution Explorer, setting the .bot file's property "Copy to Output Directory" to "Copy always"."
The details: The bot worked fine locally in the emulator. After deploying to Azure (continuous deployment), "Test in Web Chat" hung with "Waiting for bot to be ready". (Would be nice if it detected and reported errors.)
After setting up Azure storage, turning on Azure logging, discovering the FileNotFoundException, inspecting with Resource Explorer, and deploying multiple bot versions, I isolated the cause. This document really helped me troubleshoot:
https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-dotnet-visual-studio#a-nameapptracelogsacreate-and-view-application-trace-logs
I also experienced this problem but the solution I have is totally different from the suggestions above.
I created my Knowledge Base and Web App Bot purely using the portal. The problem lies with the configuration. As of writing, the Bot Template: Node.js > Question and Answer does not work. I needed to create a new Web App Bot and I selected instead C# > Question and Answer.
That fixed my problem and allowed me to use the Test in Web Chat feature.
I'm trying to integrate Watson Tradeoff Analytics service into my external project to SAP WEB IDE, so I have downloaded the following example:
github.com/dolevdotan/tradeoff-analytics-v2-vanilla-nodejs
Inside the Service on Bluemix I got the following credentials
generated
I put this credentials inside app.js
I'm running my service and it's good at the beggining, but in case of pressed button "Help Me Decide" and the following error appears:
Oops! Something went wrong
Back-end service is not available. Please try again later.
The most interesting is now! If I run the following link with deployed official TradeOff Example:
tradeoff-analytics-v2-demo.mybluemix.net/#cars
My own service will work as expected after that, without any errors. But I need to run this link first. Why so strange? What shall I do to correct it and avoid?
Thanks!
I have an MVC application that I've deployed to Azure. Offline it works with no issue with the code first development. However when deployed to Azure it just gives me a non-de-script Error advising me that there's been an error.
I have a look on the management console for further information but was only able to find an error telling me a fatal error had occurred causing a 500 error. Everything else works on the site with no issue it's just when I'm trying to do anything with the database attached to it.
To publish the app I used the downloaded publish settings from the server so I know connection string and what not are all fine. I've also set up code migrations to fill in gaps in the code first dev work so I can see what I'm missing and I don't know where to go now without a more detailed error message?
Any ideas on where I can possibly look next to try and solve this?
OK, I've created an Azure Mobile Services project in Visual Studio 2013.
I run it up as-is, then in the browser I test it by adding a todo item via the simple browser app that seems to get baked into these service projects. It gives me a '201 success' message - brilliant.
I then convert the project from IIS Express to Local IIS as the web host, recompile and try again, and although I get the same smiley face app telling me that everything is OK, when I try and add a todo item I get a 404 error. This is contrary to the Microsoft article that gives these instructions, which clearly says I am able to choose either IIS Express or Local IIS when setting up the project.
My guess is that web.config is missing something when this project runs on the local IIS server.
I'm hoping someone already has a solution before I spend hours trying to work out how to configure IIS for this type of project.
I've already wasted a load of time working through loads of bugs and gotchas with Azure Mobile, and I'm starting to run out of steam - so I'm hoping someone can help me before I go and grab an account at Parse.com
Many thanks in anticipation.
Dean
The easiest approach for your situation might be to just deploy to the cloud, and use that service for your testing. Visual Studio 2013 Update 2 makes it easy to deploy your app and connect to it for remote debugging. It is a little slower than using a local instance, but you are also assured that there will be no surprises when you eventually go live (since you are live the whole time).
That said, we will investigate the issue you are seeing with using IIS directly. Some things you might want to try on your own:
Verify that you can view the web side from your Mac's browser, to make sure that the firewall is letting the requests through.
Try using the "Getting Starting" link from the smiley-face page, to see if the REST endpoints are behaving correctly.