What defines the log type (Default, Alert, Error, Critical, etc) on logs out of a Cloud Run container instance? - debugging

I have an express server that is hosted on Cloud Run / Docker container.
This is the screen where we can view logs that come out of the deployed instance.
What defines the "type" of the log message: as in Alert, Critical, Error, Warning, Debug, Info, Notice and Default
If I log with console.error will it show up as an Error ?
What is the documentation on this subject?
UPDATE: Trying to log an error with the type Error
const logError = (msg: string | Error) => console.error(`[test:error] ${msg}`);
const testError = () : void => {
try {
throw new Error("TEST ERROR");
}
catch(err) {
const someError = new Error("HELLO ERROR");
console.log(someError);
console.error(someError);
logError(err);
logError("ERROR STRING MSG");
}
};
These were the results:
Not a single log with the type Error. Is this not supposed to be triggered by our code? When should it happen?
I'd like to filter logged messages from my catch blocks in some situations and I was hoping to filter for the Error log type. I guess I'll have to add the [error] string flag and filter for that.
How do people usually handle this?

Just install and use the Stackdriver node.js library if your goal is to send logs to Google Stackdriver (Operations Logging).

Related

Shopware 6: Cypress test - reset database failed

I try to cleanup my database with command cy.cleanUpPreviousState:
// mytest.cy.js
...
beforeEach(() => {
cy.cleanUpPreviousState()
})
...
the request was response with error:
CypressError
cy.request() failed trying to load:
http://my-route.dev.localhost:8005/cleanup
The app runs in docker container, using shyim/shopware-docker
Questions
What is wrong with my request/route?
Which controller has to take this request?
To find out what is wrong, have a log at the network tab request log.
Answering your second question: There is a special server spun up for this action. It is not a normal Shopware route.
See in the cypress.js - it is supposed to use psh.phar to clean-up when this URL is called.
const requestedUrl = request.url;
if (requestedUrl !== "/cleanup") {
response.end();
return;
}
return childProcess.exec(
`${PROJECT_ROOT}/psh.phar e2e:cleanup`,
[...]
server.listen(8005);
So things to check are:
Is that port forwarded to your docker container?
Are you using the development template and is psh.phar existing?

Cannot log stack traces with apollo server

I'm building a graphql application with apollo server and I'm having trouble figuring out how to log stack traces serverside in production mode.
I found these docs but it's not clear how to correctly log stack traces in production.
I have the following formatError function:
formatError: ((err) => {
console.error(err.originalError)
return err
})
and when one of my resolvers throws an error with NODE_ENV=production I see the following output:
Error: Unexpected error value: "could not get config value"
at locatedError (/tripvector/node_modules/graphql/error/locatedError.js:24:9)
at /tripvector/node_modules/graphql/execution/execute.js:491:54
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async execute (/tripvector/node_modules/apollo-server-core/dist/requestPipeline.js:204:20)
at async processGraphQLRequest (/tripvector/node_modules/apollo-server-core/dist/requestPipeline.js:138:28)
at async processHTTPRequest (/tripvector/node_modules/apollo-server-core/dist/runHttpQuery.js:187:30)
However, when I run in debug mode, the original error is printed as I expect:
Error: could not get config value
at validate (file:///Users/paymahn/code/tripvector/tripvector-mono/backend/lib/settings/settings.js:11:15)
at getGoogleSecret (file:///Users/paymahn/code/tripvector/tripvector-mono/backend/lib/settings/settings.js:29:12)
at Object.loginWithGoogle (file:///Users/paymahn/code/tripvector/tripvector-mono/backend/api/users/graphql/mutations.js:141:30)
at field.resolve (/Users/paymahn/code/tripvector/tripvector-mono/backend/node_modules/apollo-server-core/dist/utils/schemaInstrumentation.js:52:26)
at executeField (/Users/paymahn/code/tripvector/tripvector-mono/backend/node_modules/graphql/execution/execute.js:469:20)
at /Users/paymahn/code/tripvector/tripvector-mono/backend/node_modules/graphql/execution/execute.js:365:22
at promiseReduce (/Users/paymahn/code/tripvector/tripvector-mono/backend/node_modules/graphql/jsutils/promiseReduce.js:23:9)
at executeFieldsSerially (/Users/paymahn/code/tripvector/tripvector-mono/backend/node_modules/graphql/execution/execute.js:361:43)
at executeOperation (/Users/paymahn/code/tripvector/tripvector-mono/backend/node_modules/graphql/execution/execute.js:335:14)
at execute (/Users/paymahn/code/tripvector/tripvector-mono/backend/node_modules/graphql/execution/execute.js:130:20)
I throw the error with the following code:
function validate(val) {
if (!val) {
throw new Error('could not get config value')
}
return val
}
How can I correctly configure apollo server to print stack traces for errors, even in production?
As usual, I found the answer 2 minutes after asking. I was doing some silly error catching and rethrowing in promises which is why this problem was happening only in production.

aws-amplify subscription to appsync stops after 2 mins

When subscribing to appsync using amplify using API.graphql(graphqlOperation(subscription)); the subscription works for a while, but the I get socket closed error.
CONSOLE LOG [native code]: {
"[INFO] 24:12.893 MqttOverWSProvider": {
"errorCode": 8,
"errorMessage": "AMQJS0008I Socket closed.",
"uri": "wss://<uri>
The same subscription works in the appsync console without any issue and I get events as long as the subscription is running, but stops after around 2 mins on device.
code involved
let cs = await this.subscriptionService.appSubscriptions();
this.sbscriptions = this.cs.subscribe({
next: data => {
console.dir(data);
},
error: error => console.dir(JSON.stringify(error)),
close: () => console.log("closed")
});
This part of code throws no error, and the error shown above is only visible when setting LOG_LEVEL = DEBUG
NOTE : The subscription does work for a while before this error shows up, and in that time I can see all the events that I trigger from console.

Kony service giving 1012 opstatus Request failed error and not giving response

I have a kony sample app where I am trying to do a build and the app has one web service in it for fetching categories of some product. I have the following code also that I wrote:
function GetCategories() {
var inputparam = {
"appID": "bbuy",
"serviceID": "GetCategories",
"catId": "cat00000",
"channel": "rc",
"httpheaders": {}
};
kony.net.invokeServiceAsync("http://192.168.42.134/middleware/MWservlet",inputparam, serv_GetCategoriesCallback);
}
I am getting no response for this. Getting 1012 opstatus and the message is saying "Request failed" error.
kony.net.invokeServiceAsync("http://192.168.42.134/middleware/MWservlet",inputparam, serv_GetCategoriesCallback);
In the above line, you have not given the port number in the MWservlet URL.(e.g. 8080) Give that and check.
Also, make sure all input params are being fed to the service and that they correspond to the exact naming convention followed in the service editor.
Visit :
Find the below link. i hope it gives you a solution
http://developer.kony.com/twiki/pub/Portal/Docs/API_Reference/Content/Network_APIs.htm#net.invo2
Check the mandatory and optional fields of Inputparam

Handling errors using Parse.com Cloud Code and javascript API

What is the best way to handle errors using Parse.com Cloud Code. I'm able to use console.log and Firebug to see when Parse Cloud Code throws an error, but I need some help with how to notify the client that something went wrong. Some sample code from both sides would really be great -- Cloud Code and client side javascript code.
I preferred it this way -
On Cloud Code make one ErrorHandler.JS file -
exports.sendError = function(response, message, data) {
console.log("Message - " + message + " Data - " + JSON.stringify(data)); // To print LOG on Cloud Code
// Moreover you can use any of - "console.error/warn" - as mentioned - https://parse.com/docs/cloud_code_guide#logging
response.error({
status : false, // Indicates EXECUTION STATUS - I am using "successHandler" also & using STATUS as "true"
message : message, // Refers to Error Message
data : data || {} // Error Object or your customized Object
});
}
& client side you will have all data to print if you want or you can just show alert message to the Users.
More over it's preferred to check both SERVER side as well as CLIENT side LOG for DEVELOPING purpose because PARSE Cloud Code stores only last 100 messages in LOG.
& In order to implement proper LOGGING you must made some custom procedures with proper storage structure in terms of CLASS.
Parse has a section on Error Handling for Promises.
For instance when running a query in Cloud Code
query.find().then(function(result){ ... },
function(error){
response.error("Error occurred: " + error.message);
}
That will send error message down the client.
As an experiment I tried response.error with various strings/objects, below is what each returned (the commment shows the return value to the client).
Essentially, it always returns code 141, and you can only return a string. I was surprised that passing the proverbial err object from an exception returned {} my guess is this is for security reasons. What I do not understand is why you can't console.log(err) on the server as this has caused me a lot of confusion when trying to figure out what is going on. You basically always need to do err.message in your console.log statements to figure out what's really going on.
response.error("Some String of text") // --> {code: 141, message: "Some String of text"}
response.error( new Error("My Msg") ) // --> {code: 141, message: "{}"}
try {
var x = asdf.blah;
}catch(err) {
return response.error(err.message); // --> {code: 141, message: "asdf is not defined"}
}
response.error( err ); // --> {code: 141, message: "{}"}
response.error( Parse.Error(Parse.Error.VALIDATION_ERROR, "My Text") ); // --> {code: 141, message: "An error has occurred"}

Resources