express-http-context ns active null

Hi guys, how are you?

I'm working with your library in micro services. We have a few libraries and we save some data in context but since version 1.1.0 is not saving or getting anything. In Debugging i see that when is trying to validate if namespace exists and is active, active is null. I'm calling middleware when the express server start.

Thoughts?

Thanks! Regards!

Dec 05 '18 18:12 Lukeneo12

+1 Have the same issue too there is no active ns, so the requestId that I set for every request is undefined when i want to get it, any idea please help us with this issue.

Jan 12 '19 23:01 kouros51

Same here... It's strange, because I've got the issue only in combination with a route pointing to a passport authentication....

Mar 14 '19 08:03 thkorte

+1 here.. still investigating but I'm using this in a way pretty similar to the examples, and I always see it fail the ns.active check.

Jan 30 '20 21:01 mikemclinn

Did anyone find a solution?

Mar 04 '20 12:03 cupofjoakim

Resolution: ` use(...) {

if (!httpContext.ns.active) {
  
  let context = httpContext.ns.createContext();
  httpContext.ns.context = context;
  httpContext.ns.active = context;

}

} `

Mar 12 '20 03:03 eteixeira94

@eteixeira94 It's nice if that works for you, but we've got an active context before where we set a couple of values. Creating a new context instead does not help us get those previous values.

Mar 16 '20 15:03 cupofjoakim

@cupofjoakim It makes this instance in the creation of its initial context because this is an express-context bug. This is what I realized in debugging.

Mar 16 '20 16:03 eteixeira94

@cupofjoakim, this is only once. It's a hammer hehe

Mar 16 '20 16:03 eteixeira94

Same issue here. Solved with @eteixeira94 patch (many thanks!), but should be solved in a better way.

Apr 30 '20 12:04 jbaris

Same issue here. Solved with @eteixeira94 patch (many thanks!), but should be solved in a better way.

@jbaris, sorry I don't even know if this project is public to send a PR solving this problem, because the bug is internal, as it was urgent I solved it this way.

Apr 30 '20 14:04 eteixeira94

@eteixeira94 big things for the patch. Was banging my head against the wall for over an hour on this.

Apr 30 '20 18:04 thsteinmetz

Sorry. The @eteixeira94 patch solved the issue but give us another issue: for POST requests the context is overrided, causing unexpected behaviours. The issue was solved removing the @eteixeira94 patch and moving the context middleware after the express.json() middleware:

const express = require('express')

const app = express()
app.use(express.json())
app.use(httpContext.middleware)
app.use('/', routes)
app.listen(...)

Credits to @ortizman

May 11 '20 15:05 jbaris

Sorry, I'm already using "httpContext.middleware" in the application, but it still has an error.

20200511_125904

The error can be simulated when it is necessary to recover a value, for example, in the "beforeInsert" event at the time of the audit. OK? @jbaris

May 11 '20 15:05 eteixeira94

20200511_131606

@jbaris

May 11 '20 16:05 eteixeira94

I have experienced the same issue while working in a microservices environment and using Nodejs.

We have a service-support library which is required as a dependency in all of our Nodejs services. In our NodeJs services, we call an initialisation method present in the service-support library which sets up context/middleware needed by all of our NodeJs services (such as registering with Consul etc.).

I have used the httpContext.middleware function within the service-support library which sets a field in the httpContext on each request (as described in the express-http-context's README.md file). It worked as intended and the fields were set. I could retrieve the set fields within any file that was within the service-support package by requiring 'express-http-context' and then retrieving the set field.

The issue I had was when I required the express-http-context library from the Nodejs service which uses the service-support library. When I attempt to retrieve the set fields from the express-http-context in this context, the active field is undefined (as stated on this tickets title).

This issue only occurs on versions of express-http-context 1.1.0 and above (ie. I do not experience this issue for versions 1.0.4 and below of the express-http-context library).

This commit to the express-http-context is what caused the issue, as instead of an existing namespace being retrieved from the cls-hooked library, a new instance of the namespace is created if the library is required from a separate package.

The fix for this issue, as I see it, would be to change this line of the express-http-context index.js file to:   const ns = cls.getNamespace(nsid) || cls.createNamespace(nsid); 

Please could this internal bug be resolved, as I intend to use this library as part of my application. If any other information is required or if I have been unclear, please let me know.

Thanks

Jun 11 '21 10:06 marcdefaria

I had the same issue and ended up linking the instance from the package being used to make sure that the same instance would be used. I would also be very happy if I could get rid of this hack to make it work.