loopback.getCurrentContext() not working in a non-http context

[BerkeleyTrue]

I have a need to get the current user during change.rectify() calls after a client calls bulkUpdate.

I have limited understanding of how domains/cls work but it seems that since the juggler is not binded to the current domain/ns anywhere as the req/res objects are, the context is not preserved when the DAO emit's events.

Am I on the right track?

Using loopback 2.8.8
loopback-datasource-juggler 2.12.0

[bajtos]

@BerkeleyTrue could you please provide a test case to reproduce the problem? Ideally using a memory connector.

[bajtos]

This is a problem not specific to bulkUpdate only, it is also a problem when calling model methods from Mocha unit tests (mailing list thread) and strong-mq message listeners (gitter: subscribing to events does not involve a req object, and thus the middleware to initialize the context is not executed. Can you think of any way to read/write the context from within event subscribe (non web context)? Or perhaps there's another construct aside from req context that allows for local storage?)

[BerkeleyTrue]

I ended up changing the logic to avoid this issue. It would be nice to be able to do this in the future.

[raymondfeng]

LGTM

[bajtos]

@raymondfeng @ritch what's your opinion on getCurrentContext in browser? At the moment, it always returns null. Should I implement a shim that will always return the same context object instead?

Related: othiym23/node-continuation-local-storage#36

[BerkeleyTrue]

@bajtos Why not just use localStorage in the browser?

[bajtos]

Why not just use localStorage in the browser?

I don't understand. Why do you want to persist context in the local storage? How would you provide the default value?

Here is what I am thinking about:

// browser client
loopback.runInContext(function(context) {
  context.set('currentUser', /* data */ });
  // start the HTML5 application
});

However, since we don't have continuation-local-storage now, we can make runInContext optional and simply change loopback.getCurrentContext to return e.g .window.__loopbackCurrentContext.

// browser client
loopback.getCurrentContext().set('currentUser', /* data */);
// start the HTML5 application

Users can implement whatever persistent mechanism on top of this, for example:

var currentUser = localStorage.currentUser ? new User(JSON.parse(localStorage.currentUser)) : null;
loopback.getCurrentContext().set('currentUser', currentUser);
// start the HTML5 app

[bajtos]

We agreed with @raymondfeng and @ritch to keep returning null in the browser, as we don't have a reliable way how to provide local context in the browser.