ns active null

[Lukeneo12]

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!

[kouros51]

+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.

[thkorte]

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

[mikemclinn]

+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.

[cupofjoakim]

Did anyone find a solution?

[eteixeira94]

Resolution:
`
use(...) {

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

}

}
`

[cupofjoakim]

@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.

[eteixeira94]

@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.

[eteixeira94]

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

[jbaris]

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

[eteixeira94]

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.

[thsteinmetz]

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

[jbaris]

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

[eteixeira94]

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

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

[eteixeira94]

@jbaris

[marcdefaria]

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

[ekeuus]

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.

[t-khan-k]

Got it working after downgrading to 1.0.4

@marcdefaria thanks man. Saved my day

[fzn0x]

Just create a library that's solve this issue.

Edited : https://github.com/fzn0x/jscontext

[herbertpimentel]

+1 none of the above help me :/

[fzn0x]

+1 none of the above help me :/

I have update the link to my library :) #26 (comment)

[oliverlockwood]

For anyone reading this thread today: There is now a modern version available which:

• fixes this bug (with tests to prove it!)
• includes typing for Typescript consumers
• is based on AsyncLocalStorage instead of the deprecated cls-hooked
• may be consumed by both CommonJS and ESM Modules.

See https://www.npmjs.com/package/@dalet-oss/express-http-context and https://github.com/dalet-oss/express-http-context.