Prevent Mongoose stack trace for errors - node.js

Mongoose emits a stack trace for a cast error. I know how to prevent the Mongoose error - please do not answer how to prevent the error.
How can I stop Mongoose emitting stack trace errors in production?
Error: Argument passed in must be a single String of 12 bytes or a
string of 24 hex characters at new ObjectID
(c:\proj\fboapp\node_modules\mongoose\node_modules\bson\lib\bson\objectid.js:38:11)
at c:\proj\fboapp\routes\user\no_auth_user_api_routes.js:135:27 at
Layer.handle [as handle_request]
(c:\proj\fboapp\node_modules\express\lib\router\layer.js:95:5) at
next (c:\proj\fboapp\node_modules\express\lib\router\route.js:131:13)
at Route.dispatch
(c:\proj\fboapp\node_modules\express\lib\router\route.js:112:3) at
Layer.handle [as handle_request]
(c:\proj\fboapp\node_modules\express\lib\router\layer.js:95:5) at
c:\proj\fboapp\node_modules\express\lib\router\index.js:277:22 at
Function.process_params
(c:\proj\fboapp\node_modules\express\lib\router\index.js:330:12) at
next (c:\proj\fboapp\node_modules\express\lib\router\index.js:271:10)
at Function.handle
(c:\proj\fboapp\node_modules\express\lib\router\index.js:176:3) at
router (c:\proj\fboapp\node_modules\express\lib\router\index.js:46:12)
at Layer.handle [as handle_request]
(c:\proj\fboapp\node_modules\express\lib\router\layer.js:95:5) at
trim_prefix
(c:\proj\fboapp\node_modules\express\lib\router\index.js:312:13) at
c:\proj\fboapp\node_modules\express\lib\router\index.js:280:7 at
Function.process_params
(c:\proj\fboapp\node_modules\express\lib\router\index.js:330:12) at
next (c:\proj\fboapp\node_modules\express\lib\router\index.js:271:10)
Nodejs v0.12.3
Mongoose v4.4.3

Generally speaking, add try-catch block in the codes could be correct way to do it.
Here are my test codes without try-catch block in codes, then prevent stack trace. Refer to this module mongoose disable stack trace, also add some new errors are added into mongoose, and set Error.stackTraceLimit to 0 will disable stack trace collection.
index.js
const captureStackTrace = Error.captureStackTrace;
const CastError = module.parent.require('mongoose/lib/error/cast');
const VersionError = module.parent.require('mongoose/lib/error/version');
const ValidatorError = module.parent.require('mongoose/lib/error/validator');
const ValidationError = module.parent.require('mongoose/lib/error/validation');
const OverwriteModelError = module.parent.require('mongoose/lib/error/overwriteModel');
const MissingSchemaError = module.parent.require('mongoose/lib/error/missingSchema');
const DivergentArrayError = module.parent.require('mongoose/lib/error/divergentArray');
Error.captureStackTrace = function( that, params) {
if(that instanceof CastError ||
that instanceof VersionError ||
that instanceof ValidatorError ||
that instanceof ValidationError ||
that instanceof OverwriteModelError ||
that instanceof MissingSchemaError ||
that instanceof DivergentArrayError) {
Error.stackTraceLimit = 0;
} else if (typeof that !== 'undefined'){
captureStackTrace.apply(Error, arguments);
}
}
Error.captureStackTrace(new VersionError);
app.js
require('mongoose-disable-stack-trace');
var f = Foo({_id: new ObjectId('adss112'), key: '123'}); // invalid ObjectId
Output:
Error: Argument passed in must be a single String of 12 bytes or a string of 24
hex characters
c:\share\node\node_modules\mongoose\node_modules\mongodb\lib\server.js:283
process.nextTick(function() { throw err; }) ^
Error: Argument passed in must be a single String of 12 bytes or a string of 24
hex characters

I was confused about why errors were being rendered to the browser without an error handler, until I read the ExpressJS error handling documentation page.
Apparently there is a default error handler which is triggered when no error handler is specified.
Express comes with an in-built error handler, which takes care of any
errors that might be encountered in the app. This default
error-handling middleware function is added at the end of the
middleware function stack.
The best practice is to specify a custom error handler for production which does not output the stack trace to the browser. The default error handler always outputs the stack trace to the browser.
There is no need for try-catch blocks to route uncaught errors to the custom error handler, because Express will automatically route uncaught errors to the error handler. Also note: error handler middleware MUST specify all 4 arguments: err, req, res and next
An example of a custom error handler:
app.use(function(err, req, res, next) {
res.send('uncaught error in production');
});

Related

pdf-merger-js throws a TypeError and Fails

I have been using pdf-merger-js to merge PDF files for a while now. I have used it with PDF files I have generated from HTML files and with PDF files I did not create.
Then I started getting the error:
Uncaught TypeError: Cannot read property 'compressed' of undefined
and the merger would fail. I tried different versions of node with the same results. The version that has been working is node v12.19.1.
/* /path/to/project/mpdf.js */
const PDFMerger = require('pdf-merger-js');
const path = require('path');
(async () => {
try {
const pdfs = ['pdf1.pdf','pdf2.pdf','pdf3.pdf','pdf4.pdf','pdf5.pdf'];
const merger = new PDFMerger();
pdfs.map(f => path.resolve(__dirname, "subfolder", f)
.forEach(pdf => merger.add(pdf));
//^^^Error occurs on this line
await merger.save('all-merged.pdf');
} catch( err ) {
console.log( err );
}
})();
Has any of you worked with pdf-merger-js and, have you encountered the above error? If so, how did you resolve the error?
Stack Trace
TypeError: Cannot read property 'compressed' of undefined
at parseObject (/path/to/project/node_modules/pdfjs/lib/object/reference.js:81:15)
at PDFReference.get [as object] (/path/to/project/node_modules/pdfjs/lib/object/reference.js:15:17)
at new ExternalDocument (/path/to/project/node_modules/pdfjs/lib/external.js:20:42)
at PDFMerger._addEntireDocument (/path/to/project/node_modules/pdf-merger-js/index.js:29:15)
at PDFMerger.add (/path/to/project/node_modules/pdf-merger-js/index.js:11:12)
at /path/to/project/app3.js:10:34
at Array.forEach (<anonymous>)
at /path/to/project/app3.js:10:12
at processTicksAndRejections (internal/process/task_queues.js:97:5)
Update
I have encountered another set of PDF files that are throwing a different error on the same line:
TypeError: Cannot read property 'object' of undefined
at new ExternalDocument (/path/to/project/node_modules/pdfjs/lib/external.js:20:42)
at PDFMerger._addEntireDocument (/path/to/project/node_modules/pdf-merger-js/index.js:29:15)
at PDFMerger.add (/path/to/project/node_modules/pdf-merger-js/index.js:11:12)
at /path/to/project/app3.js:10:34
at Array.forEach (<anonymous>)
at /path/to/project/app3.js:10:12
at processTicksAndRejections (internal/process/task_queues.js:97:5)
I got the same error whenever I used compressed PDFs for merging. Seems to be a bug in the underlying pdfjs library according to a Github issue in the pdf-merger-js repository.
Not the kind of answer I was looking for ....
If you flatten the files prior to merging them then the merging works fine. This seems to resolve the two errors I encountered.
I am using pdf-flatten just before merging as follows:
const fsp = require('fs').promises;
const flattener = require('pdf-flatten');
//....
const pdfs = ['pdf1.pdf','pdf2.pdf','pdf3.pdf','pdf4.pdf','pdf5.pdf'];
for(pdf of pdfs) {
const pdfB = await fsp.readFile(path.resolve(__dirname,"subfolder", pdf));
const pdfFlat = await flattener.flatten(pdfB, {density: 300});
await fsp.writeFile(path.resolve(__dirname,"subfolder", `flattened_${pdf}`), pdfFlat);
}
//....merge the flattened files:
//.... pdfs.map(p => `flattened_${p}`).....

Why is my createIndex in Mongoose failing?

In my cart controller I have the following segments of code:
const Cart = require('mongoose').model('Cart');
This works:
cart = await Cart.findOne({email:email});
But creating an index fails:
await Cart.createIndex({email: 1});
I get the following error:
car.controller#getCart TypeError: Cart.createIndex is not a function
at exports.getCart (backend\app\controllers\cart.controller.js:49:20)
at Layer.handle [as handle_request] (node_modules\express\lib\router\layer.js:95:5)
at next (node_modules\express\lib\router\route.js:137:13)
at exports.authenticate (backend\app\controllers\user.controller.js:42:13)
The literature says: createIndex() but createIndexes (plural) works;
This issue because Mongoose's model (in this case is Cart) haven't function createIndex() so you should change createIndex() to createIndexes().
You can see docs here: https://mongoosejs.com/docs/api.html#model_Model.createIndexes

bluebird npm TypeError: Cannot read property 'call' of null

I am using bluebird npm,I am getting the above error
I am calling three different function & doing some database operation, but I am getting this error.
If I tried with two functions, it is working but with three function it is throwing error, TypeError: Cannot read property 'call' of null.
If you go to bluebird/js/release/using.js and comment the line no 39 ;
If I comment this line, then this issue is not coming & all is working fine.
If you want more info please Click Here
This is main.js
var myModule = require('../lib/myModule');
var sync = require('deasync');
var id = 90;
var moduleObj = new moduleEntity(id);
console.log(moduleObj);
var id = 90;
var moduleObj = new moduleEntity(id);
console.log(moduleObj);
var id = 90;
var moduleObj = new moduleEntity(id);
console.log(moduleObj);
In MyModule.js
var deasync = require('deasync');
var dbEntity = require('../db/dbEntity');
module.exports = function (id) {
var outputEntity;
dbEntity(id, function(data){
outputEntity = data
});
while(outputEntity === undefined) { deasync.runLoopOnce();};
return outputEntity;
};
In dbEntery.js
var Promise = require("bluebird");
var getConnection = require('./dbcon');
module.exports = function (id,cb) {
var sql_getRecords = SELECT * from tanle_name;
Promise.using(getConnection, function (conn) {
return conn.query(sql_getRecords).then(function(data){
cb(data[0]);
})
});
};
Here is error stack trace
TypeError: Cannot read property 'call' of null
at FunctionDisposer.doDispose (/home/user/Projects/project_name/node_modules/bluebird/js/release/using.js:98:18)
at FunctionDisposer.Disposer.tryDispose (/home/user/Projects/project_name/node_modules/bluebird/js/release/using.js:78:20)
at iterator (/home/user/Projects/project_name/node_modules/bluebird/js/release/using.js:36:53)
at dispose (/home/user/Projects/project_name/node_modules/bluebird/js/release/using.js:48:9)
at /home/user/Projects/project_name/node_modules/bluebird/js/release/using.js:194:20
at PassThroughHandlerContext.finallyHandler (/home/user/Projects/project_name/node_modules/bluebird/js/release/finally.js:55:23)
at PassThroughHandlerContext.tryCatcher (/home/user/Projects/project_name/node_modules/bluebird/js/release/util.js:16:23)
at Promise._settlePromiseFromHandler (/home/user/Projects/project_name/node_modules/bluebird/js/release/promise.js:510:31)
at Promise._settlePromise (/home/user/Projects/project_name/node_modules/bluebird/js/release/promise.js:567:18)
at Promise._settlePromise0 (/home/user/Projects/project_name/node_modules/bluebird/js/release/promise.js:612:10)
at Promise._settlePromises (/home/user/Projects/project_name/node_modules/bluebird/js/release/promise.js:687:18)
at Async._drainQueue (/home/user/Projects/project_name/node_modules/bluebird/js/release/async.js:133:16)
at Async._drainQueues (/home/user/Projects/project_name/node_modules/bluebird/js/release/async.js:143:10)
at Immediate.Async.drainQueues (/home/user/Projects/project_name/node_modules/bluebird/js/release/async.js:17:14)
at runCallback (timers.js:651:20)
at tryOnImmediate (timers.js:624:5)
Bluebird version -- 3.5
Node Version -- v7.6.0
You provided no code examples so it's hard to give you any detailed answer but here are some things that you have to keep in mind when you get error like this.
TypeError: Cannot read property 'call' of null means that some code (also impossible to tell you which code because you didn't provide an example and full error stack trace) tries to bind some function to some this object and arguments using Function.prototype.call() - see:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/call
but instead of the function it got null.
Now you need to follow the stack trace and see which code is trying to call the function and where the null originated to fix your problem.
Note that it is null and not undefined so it must have been provided explicitly instead of just being a missing argument to a function call or a missing property on an object. This is an important hint that should let you diagnose the problem much easier.

Bluebird warning "A promise was created in a handler but was not returned from it"

I get the warning about not returning a created promise from Bluebird and I do not understand why and how I should rewrite my code.
(I have tried reading about the warning at Bluebird API page and the anti-pattern page as I suspect this is what I'm doing)
In my view.js file:
var express = require('express'),
router = express.Router(),
settings = myReq('config/settings'),
Sets = myReq('lib/Sets'),
log = myReq('lib/utils').getLogger('View');
router.get('/:setId/', function(req, res, next) {
var
setId = req.params.setId,
user = req.user,
set = new Sets(setId, user);
log.info('Got a request for set: ' + setId);
// The below line gives the warning mentioned
set.getSet().then(function(output) {
res.send(output);
}).error(function(e){
log.error(e.message, e.data);
res.send('An error occurred while handling set:' + e.message);
});
});
module.exports = router;
In my Sets.js file I have:
var
Promise = require('bluebird'),
OE = Promise.OperationalError,
settings = myReq('config/settings'),
UserData = myReq('lib/userData'),
log = myReq('lib/utils').getLogger('sets'),
errorToSend = false;
module.exports = function(setId, user) {
var
sets = myReq('lib/utils').getDb('sets');
return {
getSet : function() {
log.debug('Getting set')
return sets.findOneAsync({
setId:setId
}).then(function(set){
if ( set ) {
log.debug('got set from DB');
} else {
set = getStaticSet(setId);
if ( ! set ) {
throw new OE('Failed getting db records or static template for set: ' + setId );
}
log.debug('got static set');
}
log.debug('I am handling set')
if ( ! checkSet(set) ) {
var e = new OE('Failed checking set');
e.data = set;
throw e;
}
return {
view : getView(set),
logic : set.logic,
canEdit : true,
error : errorToSend
};
});
}
};
};
So the line in my view.js file with "set.getSet()" gives the warning about not returning the created promise. It seems like this script still does what I expect it to do, but I do not understand why I get the warning.
Stacktrace:
Warning: a promise was created in a handler but was not returned from it
at Object.getSet (C:\dev\infoscrn\lib\Sets.js:36:25)
at C:\dev\infoscrn\routes\view.js:39:20
at Layer.handle [as handle_request] (C:\dev\infoscrn\node_modules\express\lib\router\layer.js:82:5)
at next (C:\dev\infoscrn\node_modules\express\lib\router\route.js:110:13)
at Route.dispatch (C:\dev\infoscrn\node_modules\express\lib\router\route.js:91:3)
at Layer.handle [as handle_request] (C:\dev\infoscrn\node_modules\express\lib\router\layer.js:82:5)
at C:\dev\infoscrn\node_modules\express\lib\router\index.js:267:22
at param (C:\dev\infoscrn\node_modules\express\lib\router\index.js:340:14)
at param (C:\dev\infoscrn\node_modules\express\lib\router\index.js:356:14)
at Function.proto.process_params (C:\dev\infoscrn\node_modules\express\lib\router\index.js:400:3)
at next (C:\dev\infoscrn\node_modules\express\lib\router\index.js:261:10)
at Function.proto.handle (C:\dev\infoscrn\node_modules\express\lib\router\index.js:166:3)
at router (C:\dev\infoscrn\node_modules\express\lib\router\index.js:35:12)
at Layer.handle [as handle_request] (C:\dev\infoscrn\node_modules\express\lib\router\layer.js:82:5)
at trim_prefix (C:\dev\infoscrn\node_modules\express\lib\router\index.js:302:13)
at C:\dev\infoscrn\node_modules\express\lib\router\index.js:270:7
at Function.proto.process_params (C:\dev\infoscrn\node_modules\express\lib\router\index.js:321:12)
at next (C:\dev\infoscrn\node_modules\express\lib\router\index.js:261:10)
at C:\dev\infoscrn\node_modules\express\lib\router\index.js:603:15
at next (C:\dev\infoscrn\node_modules\express\lib\router\index.js:246:14)
First, try and update all your dependencies. There's been a recent version of Bluebird, which fixed an issue involving this warning.
Next, make sure you return from all your handlers.
Then, if you still get the warning (like I do) you can disable this specific warning. I chose to do so by setting BLUEBIRD_W_FORGOTTEN_RETURN=0 in my environment.
Don't disable warnings. They're there for a reason.
The typical pattern is that if your onfulfill or onreject handler causes a Promise to be constructed, it will return that Promise (or some chain derived from it) from the handler, so that the chain adopts the state of that Promise.
So Bluebird is keeping track of when it is running one of your handler functions, and also keeping track of when it's Promise constructor is called. If it determines that a Promise was created at any point while your handler is running (that includes anywhere down in the callstack), but that Promise was not returned from your handler, it issues this warning because it thinks you probably forgot to write the return statement.
So if you legitimately don't care about the Promise that was created inside the handler, all you have to do is explicitly return something from your handler. If you don't care about what is returned from your handler (i.e., if you don't care what value the Promise fulfills with), then simply return null. Whatever you return, the explicit return (specifically, a return value other than undefined) tells Bluebird that you think you know what you're doing, and it won't issue this warning.
Make sure that every place you have return statement which is the solution works for me.

res.render causes native err after call to fs.stat / fs.access

I'm trying to build a catch-all route for a subset of my site that contains multiple directories/pages that need to be processed by ejs, but don't need specific routes.
[N.B., I included the sync version in the example below to remove any question of timing... the analogous implementation of fs.stat (and of fs.access) results in the same behavior]
router.get('/foobar/:page(*)', function(req, res, next) {
var fs = require('fs');
var path = require('path');
var viewsPath = req.app.get('views');
try
{
// see if there's an ejs file corresponding to request
var stats = fs.statSync(path.join(viewsPath, 'foobar', req.params.page + '.ejs'));
console.log(stats); // stats object seems accurate
// THROWS WHEN CALLING openSync
res.render('foobar/' + req.params.page, {title: 'foo'});
}
catch (e)
{
var err = new Error();
err.status = 404;
next(err);
}
}
The 404 path works just fine, but when I request a page that actually exists, the render call throws:
Unexpected error code undefined has occurred. Please retry your request
at Error (native)
at Object.fs.openSync (fs.js:500:18)
at Object.fs.readFileSync (fs.js:352:15)
at includeSource (C:\Users\Jim\Documents\myProject\node_modules\ejs\lib\ejs.js:194:17)
at C:\Users\Jim\Documents\myProject\node_modules\ejs\lib\ejs.js:528:26
at Array.forEach (native)
at Object.Template.generateSource (C:\Users\Jim\Documents\myProject\node_modules\ejs\lib\ejs.js:505:15)
at Object.Template.compile (C:\Users\Jim\Documents\myProject\node_modules\ejs\lib\ejs.js:427:12)
at Object.compile (C:\Users\Jim\Documents\myProject\node_modules\ejs\lib\ejs.js:288:16)
at handleCache (C:\Users\Jim\Documents\myProject\node_modules\ejs\lib\ejs.js:147:16)
at View.exports.renderFile [as engine] (C:\Users\Jim\Documents\myProject\node_modules\ejs\lib\ejs.js:350:14)
at View.render (C:\Users\Jim\Documents\myProject\node_modules\express\lib\view.js:126:8)
at tryRender (C:\Users\Jim\Documents\myProject\node_modules\express\lib\application.js:639:10)
at EventEmitter.render (C:\Users\Jim\Documents\myProject\node_modules\express\lib\application.js:591:3)
at ServerResponse.render (C:\Users\Jim\Documents\myProject\node_modules\express\lib\response.js:961:7)
at C:\Users\Jim\Documents\myProject\routes\power-essentials.js:32:7
at Layer.handle [as handle_request] (C:\Users\Jim\Documents\myProject\node_modules\express\lib\router\layer.js:95:5)
at next (C:\Users\Jim\Documents\myProject\node_modules\express\lib\router\route.js:131:13)
at Route.dispatch (C:\Users\Jim\Documents\myProject\node_modules\express\lib\router\route.js:112:3)
at Layer.handle [as handle_request] (C:\Users\Jim\Documents\myProject\node_modules\express\lib\router\layer.js:95:5)
at C:\Users\Jim\Documents\myProject\node_modules\express\lib\router\index.js:277:22
at param (C:\Users\Jim\Documents\myProject\node_modules\express\lib\router\index.js:349:14)
It's behaving almost like the fs.statSync call has placed a lock on the file that render chokes on when trying to open the view file.
occams razor: the test page I was working with had an invalid include path reference within it! It wasn't complaining about the template I was trying to load, but rather one referenced within it.

Resources