I have a Parse Cloud Code written in JavaScript, I have an code-based system so I have 3 different modes:
Code is found and have't been used before - SUCCESS
Code is found and have been used before - ERROR
Code isn't found - ERROR
Now, when the client (iOS) gets the success - everything works fine and the code is OK. But I want to determinate between the 2 errors I have and tell the user what's wrong (your code isn't available anymore/code not found), but the error code Parse sends is always 141, so I don't know which message should I print to the user.
How can I change the error code of the error/another way to detect what error is it on client/server side?
Thank you!
From https://parseplatform.github.io/docs/js/guide/#error-codes:
ScriptFailed 141 Cloud Code script failed. Usually points to a JavaScript error. Check error message for more details.
FunctionNotFound 141 Cloud function not found. Check that the specified Cloud function is present in your Cloud Code script and has been deployed.
JobNotFound 141 Background job not found. Check that the specified job is present in your Cloud Code script and has been deployed.
SuccessErrorNotCalled 141 success/error was not called. A cloud function will return once response.success() or response.error() is called. A background job will similarly finish execution once status.success() or status.error() is called. If a function or job never reaches either of the success/error methods, this error will be returned. This may happen when a function does not handle an error response correctly, preventing code execution from reaching the success() method call.
MultupleSuccessErrorCalls 141 Can’t call success/error multiple times. A cloud function will return once response.success() or response.error() is called. A background job will similarly finish execution once status.success() or status.error() is called. If a function or job calls success() and/or error() more than once in a single execution path, this error will be returned.
So looking above, you could have a Javascript error occurring during the function's run. You could be spelling the function name wrong when calling. You could forget to call response.success() to properly close the function. Or you could be calling response.success() / response.error() too many times, make sure that as you follow your code's logic, you only hit one of these for every path.
If you could post the code for your Cloud Code, we might be able to further help you.
Related
When I am importing more than 300 record in firebase using google cloud function than am getting error :
Error: function crashed out of request scope Function killed.
Function execution took 31903 ms, finished with status: 'connection error'
Without a glimpse into your code, I only can guess. "Function crashed outside of request scope" indicates that the cloud function had finished before the asynchronous function(s) did. See for documentation for handling async functions and promises:
https://firebase.google.com/docs/functions/terminate-functions
Take a closer look at your returns. Make sure you don't forget to return the promise to functions. For an example see also here: https://github.com/firebase/firebase-functions/issues/18#issuecomment-288375709
I had the same problem and it ended up being a problem with the mysql connection I was using in the project.
In this case I used https://www.npmjs.com/package/mysql2 and the system was losing connections to the database.
It was not clear where it was happening and I got the following errors and no indication where the problem was occurring.
- Error: function crashed out of request scope Function killed.
- Function execution took 31903 ms, finished with status: 'connection error'
Placing try..catch around the database calls revealed the correct error and location where it was happening.
Yout might have gone passed a limit, please look at https://firebase.google.com/docs/database/usage/limits.
If this is the case, you could use multiple databases.
In a NodeJS 6.10.2/SailsJS 0.12.13 based JavaScript application I experience since several months a strange error behavior.
In a Sails controller, I try to retrieve a property of a literal object:
console.log(someObject.someProperty);
console.log("I am still here!");
However, in my case someObject is undefined. So, I'd expect to get an error like 'Cannot read property someProperty of undefined.' - and then either Node.js to stop completely or the code to go on (with the next console.log).
Instead, the code simply stops executing at that point and I get a strange warning: "(node:4822) Warning: Possible EventEmitter memory leak detected. 11 close listeners added. Use emitter.setMaxListeners() to increase limit." It is however, unpredictable how often this error occurs. Somethings only once, somethings about 20 times right after each other.
What I found out so for is that it is somehow connected to the question whether there was already a response or not. Consider the following:
mySailsControllerFunction: function(req, res) {
console.log(someObject.someProperty);
console.log("I am still here!");
res.json({"foo":"dahoo"});
}
This will result in Sending 500 ("Server Error") response: ReferenceError: someObject is not defined - exactly what I expect.
However, now I first send some response and then trying to access my non existing property, turning the code into:
mySailsControllerFunction: function(req, res) {
res.json({"foo":"dahoo"});
setTimeout(function () {
console.log("Yeah!");
console.log(someObject.someProperty);
console.log("I am still here!");
},1000);
}
then I often get simply nothing: 'Yeah!' displayed, but nothing comes afterwards. The event listener error is sometimes there, sometimes not. Very strange.
Additionally, and strange enough, the problem seems to be somehow connected to the time passed since the start of Sails. I put the code you see above inside a Sails controller function which is called immediately after the clients re-connect. I then played around with the timeout values, restarting the Sails server several times. Outcome: If I set the timeout to 1s, in 4 of 5 tests, I will get the correct error behavior. For 10 seconds it is about 50%, for 30s the error will always be ignored without any console output.
However, if I put my test code outside of the Sails controller, I always get the correct error behavior by Node. So, I'm quite sure this is a wrong behavior of Sails, not Node.
Disclaimer: I don't know Sails. So it may or may not be related, but my answer may offer a clue.
From the Sails documentation:
http://sailsjs.com/documentation/reference/response-res/res-json
This method is terminal, meaning it is generally the last line of code
your app should run for a given request (hence the advisory usage of
return throughout these docs).
Thus, when you use res.json({"foo":"dahoo"});, Sails probably sends the response back to the client, closing the call sequence, which, if it uses Promises or some other async mechanism, may kind of "swallow" further code, as also suggested in an above comment. This is probably internal coding in Sails, so it's not immediately obvious from the outside WHY your second code block specifically doesn't work.
So you should stick to the first pattern: access your property first, and put res.json() at the end of the controller function.
For reference: I finally solved that issue.
There were, somehow hidden in the code, process exit handlers defined:
process.on('exit', myErrorFunction.bind());
process.on('SIGINT', myErrorFunction.bind());
process.on('uncaughtException', myErrorFunction.bind());
The problem was: The function in which these lines were in was bound to a cronjob. So, each time the cronjob executed, new handlers were registered. So, my assumption above (before vs. after response) was wrong: In fact everything worked till the cronjob was executed for the first time. From then on, it didn't. And eventually, the warning was fired (correctly!).
I would have never found out without this answer: Make node show stack trace after EventEmitter warning
You have to add one line of code to get the stack trace:
process.on('warning', e => console.warn(e.stack));
Additionally, speaking of stack traces: In the Sails serverError response (api/api/responses/serverError.js), it is convenient to access it like this:
module.exports = function serverError (data, options) {
console.log(data.stack);
/* ... */
};
I have a server and client side GAS app. The client side needs to run a function on the server. If for any reason, (like no internet connection), the connection is unsuccessful, I want it to gracefully alert the user. I tried this, but it doesn't work:
try{
google.script.run
.withSuccessHandler(onSuccess)
.myFunction();
return;
}
catch(e){
alert('Cannot connect to server: ' + e.message());
}
Using Chrome 46, the console spits out the error correctly: "net::ERR_INTERNET_DISCONNECTED". However, the alert doesn't appear. The console also says: "Uncaught NetworkError: Connection failure due to HTTP 0".
Why am I not able to catch the exception?
edit: as explained here (https://softwareengineering.stackexchange.com/questions/144326/try-catch-in-javascript-isnt-it-a-good-practice), maybe it has to do with the async nature of the calls. Can someone confirm this?
I want to confirm whether Apps Script functions in a spreadsheet container-bound project can or cannot be called via google.script.run from within a JavaScript function in an HTML template that was loaded by the HTMLService. My initial findings indicate "not" (see below), but I might be missing something.
The google.script.run call, when made from within the JS function called by the onclick handler, consistently routes to the error handler function, with the following error code: NetworkError: Connection failure due to HTTP 0.
If I call the google.script.run code directly from the onclick handler of a button, it does run. I'd prefer to be able to use it in a function, so that I can build up a set of data to pass into the real method I'm planning for the implementation.
The error you see is because you close the sidebar with that line, severing connection to the server-side script.
I have written a cloud function that is working well.
Sometimes this function is being executed more than one time for the same user (I made sure that only one request is being requested from the client android app).
After some debugging I noticed that this problem happens if the connection is bad. I may be or may not be correct.
How to overcome such an issue?
As in the comments I also don't believe the client SDKs would duplicate a Cloud Function call on a bad connection. The expected behaviour would be for them to throw a network-related exception on the client side and not call it again. A problem would arise if the Cloud Function runs successfully and the client is only unable to get the result back.
I can think of the following solutions, with no more details about the Cloud Function itself:
Try to make the function idempotent - Meaning that even if it runs twice the end result is the same, assuming the same input/parameters.
Cache the results and manually throttle the function - This is more complicated, and is only needed if the network problem persists and you can't work around eliminating the side effects of the function. You would have to create another Class to cache the results of the function (maybe keyed by the parameters) and returning the same result with no computation and side effects.
node.js doc says
response.end([data], [encoding])
This method signals to the server that all of the response headers and body have been sent; that server should consider this message complete. The method, response.end(), MUST be called on each response.
but in the many examples given using using createReadStream, eg,
fs.createReadStream(filename,{...}).pipe(response)
I never see response.end() called.
it resonse.end() needed with createReadStream()? and, if so, where does it appear in the program flow - you don't want it called until the pipe is finished, right?
You do response.end() after reading is finished (end event) or you encounter an error (error event).
Check this example: http://elegantcode.com/2011/04/06/taking-baby-steps-with-node-js-pumping-data-between-streams/