loopback.getCurrentContext() is null

[jmenashe]

This may be related to #631. This method returns null intermittently for some remote methods. I am using loopback v2.13.0, loopback-datasource-juggler v2.32.0, and async 1.0.0. Here is an example:

function getData(AccountModel, id, callback) {
  var loopback = require('loopback');
  console.error(loopback.getCurrentContext()); // consistently null
}
  AccountModel.getData = getData.bind(this, AccountModel);
  AccountModel.remoteMethod('getData', {
    description: "Get the " + name + "'s data.",
    accepts: [
      {arg: "id", type: "string", description: "The " + name + "'s id", required: true, http: { source: "path" }},
    ],
    http: {verb: "get", path: "/:id/get_data"},
    returns: {arg: "data", type: "object", root: true}
  });

[jmenashe]

Since this seems to be a recurring issue with loopback, is there some workaround? If I can't have access to the request context then it means I can't use these remote method handlers at all.

[raymondfeng]

See strongloop/loopback#1495 strongloop/loopback#1495

Thanks,

---

Raymond Feng
Co-Founder and Architect @ StrongLoop, Inc.

StrongLoop http://strongloop.com/ makes it easy to develop APIs http://strongloop.com/mobile-application-development/loopback/ in Node, plus get DevOps capabilities http://strongloop.com/node-js-performance/strongops/ like monitoring, debugging and clustering.

On Jul 8, 2015, at 4:24 AM, Jacob Menashe notifications@github.com wrote:

Since this seems to be a recurring issue with loopback, is there some workaround? If I can't have access to the request context then it means I can't use these remote method handlers at all.

—
Reply to this email directly or view it on GitHub #657 (comment).

[ryedin]

so, something recently changed which broke .getCurrentContext in all remote methods? which is why our code that relies on this in all of our before save hooks now no longer works?

And you don't intend to fix the .getCurrentContext bug, but instead are recommending that we implement this code in strongloop/loopback#1495?

I just want to be clear here. Is that what you are effectively saying by the above post?

EDIT: not trying to sound snarky... just want to understand the best way to fix our app now (wait until you fix the .getCurrentContext bug that has been introduced, or attempt to hack the context in via 1495 above)

[ritch]

Since this seems to be a recurring issue with loopback, is there some workaround?

strongloop/loopback#1495 is my proposal for a work around. The downside is that you must manually pass the options.remoteCtx to wherever it is needed.

so, something recently changed which broke .getCurrentContext

This is certainly concerning. We should fix this. We intend to fix any bug that prevents you to use any aspect of LoopBack. But practically speaking, the getCurrentContext() method relies on an extremely obscure and complicated context propagation. This has burned many people, and also has a potential to limit performance under high concurrency.

Personally I recommend to migrate to the strongloop/loopback#1495 work around. I expect this will eventually land as a first class citizen in strong-remoting and loopback core.

not trying to sound snarky

Trust me I can totally relate. I'm building several applications on LoopBack, and I have the same concern that you do. Personally, I have not made the jump to using getCurrentContext() (even though its something I've wanted for quite a while). So moving forward I'm only going to depend on the manual passing of the options object along with a remoteCtx property (the 1495 approach). To me its worth the added pain so I don't have to worry about modules outside of loopback breaking cls (the complex context propagation I mentioned above).

[ryedin]

OK, thank you for the detailed response. I will commence adding the context injection and ripping out our reliance on getCurrentContext().

[wprater]

how would one get context information in a middleware if we're to remove the use of getCurrentContext? we are having major issues now with the strongloop/loopback#1495 "fix"

[jmenashe]

The simplest way to access the context is to bypass strongloop's remote method tools and specify handlers with express. From there you can access the context directly and pass it along with all of your function calls. It's an unfortunate solution but at the end of the day I would rather have something gritty and consistent than something nifty that works half the time.

[wprater]

are you saying to remove the remoteMethod calls to setup the endpoints? Or just to not use the getCurrentContext tools or the strongloop/loopback#1495 workaround, which has terrible performance? it's brought our app to the ground.

[jmenashe]

The former. Actually in our experience the endpoints created with remoteMethod leaked memory pretty badly. For high-volume endpoints we therefore went with straight express.and passed the context around manually.

[wprater]

that's sad to hear, I cannot remove our remoteMethod as we're close to shipping and they are the basis of our documentation as well.

I did manage to fix the performance issue with the 1495 hack.

[fabien]

@wprater could you please elaborate on the performance issue and possible fix? I'm about to head for the 1495 hack, but I'd like to know if I'm in for more trouble then.

[wprater]

@fabien you can see my notes here strongloop/loopback#1495 (comment) for a possible work around to fix these issues. but you might also start to read up on the discussions here too strongloop/loopback-context#2

[fabien]

@wprater which notes? Thanks in advance!

[wprater]

@wprater which notes? Thanks in advance!

@fabien updated the comment above

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.