Node.js process.domain undefined sometimes

Question

In a Node.js project with LoopbackJS I need to store data during a request.

So, I used domain :

// pre-processing middleware app.use(function (req, res, next) { // create per request domain instance var domain = require('domain').create(); // save request and response to domain, to make it accessible everywhere domain.req = req; domain.res = res; domain.run(next); }); 

Later in the required module:

 Model.beforeRemote('**', function(oContext, oModel, next) { // Save method name for later use process.domain.remoteContext = { /* Here is an error thrown */ methodName: oContext.method.name }; ... process.domain.res.send() // example of usage }) 

BUT, but when I make a request from Safari or IE, process.domain is sometimes undefined! A request from Chrome or Firefox is working as expected. Any suggestions?

Error response:

 {"error":{"name":"TypeError","status":500,"message":"Cannot set property 'remoteContext' of undefined","stack":"TypeError: Cannot set property 'remoteContext' of undefined\n at module.exports (/Users/igormatyushkin/projects/Yash/server/hooks/admin-remote.js:12:34)\n at Function.Model.setup.ModelCtor.beforeRemote.args (/Users/igormatyushkin/projects/Yash/node_modules/loopback/lib/model.js:184:9)\n at execStack (/Users/igormatyushkin/projects/Yash/node_modules/loopback/node_modules/strong-remoting/lib/remote-objects.js:363:13)\n at RemoteObjects.execHooks (/Users/igormatyushkin/projects/Yash/node_modules/loopback/node_modules/strong-remoting/lib/remote-objects.js:372:10)\n at RemoteObjects.invokeMethodInContext (/Users/igormatyushkin/projects/Yash/node_modules/loopback/node_modules/strong-remoting/lib/remote-objects.js:512:8)\n at async.series.results (/Users/igormatyushkin/projects/Yash/node_modules/loopback/node_modules/strong-remoting/node_modules/async/lib/async.js:610:21)\n at _asyncMap (/Users/igormatyushkin/projects/Yash/node_modules/loopback/node_modules/strong-remoting/node_modules/async/lib/async.js:249:17)\n at async.eachSeries.iterate (/Users/igormatyushkin/projects/Yash/node_modules/loopback/node_modules/strong-remoting/node_modules/async/lib/async.js:149:13)\n at async.eachSeries (/Users/igormatyushkin/projects/Yash/node_modules/loopback/node_modules/strong-remoting/node_modules/async/lib/async.js:165:9)\n at _asyncMap (/Users/igormatyushkin/projects/Yash/node_modules/loopback/node_modules/strong-remoting/node_modules/async/lib/async.js:248:13)"}} 

Answer 1

It just turned out that binding the binding to the action and res to the domain at the time of creation allows undefined domains down in the execution stack.

 app.use(function (req, res, next) { // create per request domain instance domain.create().run(function() { // explicit binding process.domain.add(req) process.domain.add(res) // save request to domain, to make it accessible everywhere process.domain.req = req; process.domain.res = res; next() }); }); 

I do not know why this is happening, so I leave the question open to other possible advice.

Answer 2

It should be noted that domains are not designed to handle errors in this way . Instead, it is assumed that the domains will be used to secure the modules of the whole application (for example, perhaps you want to run third-party code in the sandbox). There is no need for a domain (although you can of course use it)

In addition, process.domain installed only if this function is executed from the domain stack. You do not provide information about the model call site, so I can only assume that your model is being called from outside this stack, which causes an error.

Given that you are connecting to beforeRemote , which executes before , the remote action is executing, I'm going to assume that it is being called from outside the domain stack and therefore process.domain is the undefined expected behavior.

Answer 3

For the reader of this question, it is important to know that the Node Domain Module is outdated and should not be used.

If you came here to find a solution to this problem, you would be better off looking for something other than a domain module.

This module is awaiting cancellation. After the replacement API is complete, this module will be completely out of date. Most end users should have no reason to use this module. Users who absolutely must have the functionality provided by the domains can count on this, but in the future they will have to switch to another solution.

Although this does not technically answer the OP question, I believe that this is the right “solution” for most readers of this question.

An alternative to using a domain is the continuation-local-storage module.