I'm setting my Node.js project with swaggerize-express, and are currently testing my backen using supertest to test my backend.
When I run the supertests, and it fails due to swagger rejecting (i.s. input validation fails) the data I pass to it, currently I simply get a 400 error message, without any details on what's wrong with my query.
I'd like the backend to provide some hints as to what input data it rejects. I haven't found any debug options to set in swaggerize-express, so how can I go about getting the backend to ouput some details on the validation errors? Wether the validation errors are provided in the server log or in the data returned to the client is not important at this point, although I'd prefer the latter.
if you deploy your API in a Microsoft Azure App Service you will take benefit of the Output Logs.
Check my post on how to deploy a node.js API quickly in Azure:
http://mosshowto.blogspot.fr/2017/10/try-azure-app-service.html
When it's deployed, go to the Visual Studio Code online editor, check your deployment.Then, Hit the run button. The server will try to start your API and will log any error in the output if needed:
Related
I have an Azure Function of type Queue Trigger hosted on Azure with App Service Plan on B1.
That function makes an HTTP request to a website and downloads the HTML. When I debug the function locally and add messages to the queue everything works fine, but when I deploy it and run it on the Azure environment then it gives a 503 error.
This error is consistent with a specific website, other websites work just fine.
I first thought that the problem was with the library that I used to make the HTTP request, but I tried HttpClient, Refit, RestSharp, and they all have the same result. I also tried to get the HttpClient using the dependency injection as described on Microsoft docs but the error is the same.
After many tries I concluded that the code is not the problem, I connected to Azure Console (Development Tools) and run the curl command with the -I parameter to check the HTTP status, the result was 503, on my computer when I run the curl command, it gives me status 200.
Thank you Almis and Skin. Posting your discussions as answer to help other community members.
Website that you are trying to work with is well aware of Azure IPs and are getting blocked. This is resulting in 503 errors.
I have written some simple functions and enabled Application Insights,
Its all showing as connected and I can see that's its tracking http statues, eg I get a failed request count and server response times etc.
I understand that I can add application insights to node with the following code
let appInsights = require("applicationinsights");
appInsights.setup("[your ikey]").start();
But I was hoping it would just work without this, I can see that the function is outputting logs when I use the log stream
But when I use app insights I don't see anything in any of the log tables
Do I need to add insights via code to my function or I am missing some secret config option.
That's also a good idea to add application insights module into your node project to achieve monitor feature for your function. Both code and codeless are good choices.
In my opinion, the biggest difference between code and codeless monitor is the custom telemetry data. But I think in most scenarios, default information collected is enough for daily using, official doc says:
Application Insights collects log, performance, and error data, and
automatically detects performance anomalies.
So I think it's ok for you when you could get traces and error messages after adding appinsights module and recreate a new appinsights instance. And you can also try to use codeless configuration I mentioned in the comment(azure portal-> your function written by nodejs-> Application insights-> enable-> create new resource)
My requirement is to send the error to developers whenever an error occurs in the project (ex: unable to fetch the user from the database, var x is not defined, myfun() is not a function etc.)
We are using
NODE for backend language
Express for routing
GCP for deployment
PM2 package for management
Express default error handling is not working because we have many async codes, and it's very difficult to check and modify the project using express next() function.
I didn't find any way to report project error via GCP
and report error via pm2 is not working
Please tell me any third party package to report project errors or any other way of reporting.
User Stackdriver as already advised, and for Stackdriver to be useful, make sure that all errors are logged properly in your code, so that meaningful error messages are displayed in your Stackdriver reports.
Check this post for different methods of catching errors with Javascript, and how to deal with asynchronous calls.
I've deployed a node.js chatbot (built using Microsoft Botbuilder package) as an Azure web app. As seen in the attached image, the conversation in channel emulator(same with web chat) goes on smoothly until there's a db call. The part were the intent handler tries to do db call, the bot responds with the default error text(I didn't understand. Please try again.).
Interestingly, if I type in something random( like a Hello) in response followed by the query again, the bot goes ahead with the db call. This scenario is shown in the attached screenshot.
Strangely, the issue doesn't happen when I work on the bot locally or deploy it outside Azure (say AWS).
My question is how do I figure out what exactly is going wrong here ? I have been going through the logs in the Diagnostic Console(Kudu) of my Azure web app, but no pointers in any of the logs. Any help is appreciated!
edit: Got it fixed by following the steps from this link
I am setting up an ASP.NET WebApi application running on the Azure web application environment. Most of my controllers and endpoints work fine, but there are about 10 routes that return 500 errors "An error has occured". It's not random. It's the same routes every time and I can find no pattern (not all the HTTP methods, from different controllers where other routes in that same controller work fine, and so forth)
When these errors occur, no error logging gets triggered as far as I can tell in the app. (I am using Raygun.IO if that matters). I tried adding a global.asax file with following lines in the Application_Error function:
Exception ex = Server.GetLastError();
new RaygunClient().SendInBackground(null, ex);
but as far as I can see, it doesn't get triggered when these 500 errors occur. The only thing I have found in the Azure server logs is the following warning in the Failed Requests log:
However, I don't see any errors in the trace previous to that point. I'm also not finding any other errors in any of my Azure logs that I can relate to these failing routes.
It's .NET 4.6 (tried 4.5.1 and 4.5.2 with no difference) WebApi using an OWIN startup class. Also tried updating all my packages to no effect.
Check to be sure you don't have routes that conflict. When a URI matches two or more controller actions, and thus Web API can't pick one, you will get a 500 error.
If you have a consistent repro, then you can use remote debugging to attach to your web app and debug it (https://azure.microsoft.com/en-us/documentation/articles/web-sites-dotnet-troubleshoot-visual-studio/). If you can repro it through the browser, you can also turn the custom errors page off so that it shows the stack trace through the browser (<customErrors mode="off"/> under <server.web>).
Also, you can enable better diagnostic logs using the web app settings. Information on how to do so is here: https://azure.microsoft.com/en-us/documentation/articles/web-sites-configure/ under the section "Enabling diagnostic logs".
Also, as Brent said, URL conflicts can cause some nasty errors which aren't immediately obvious.
I figured out what was going on. There were actual errors occurring (mostly SQL related), but the way that we had configured the functions and error logging in those functions, the actual errors were being swallowed up and lost, overriding the error logging behavior of Raygun. I went through and ripped out the Try/Catch blocks we were using for error trapping and logging and the real errors finally emerged into the Raygun dashboard.