Stephen Belanger

I would recommend against using `enterWith(...)`. There's a strongly-worded warning against its use in the docs for a good reason. There are _lots_ of cases like this one where persisting...

I'll have a bit of time to look at it tomorrow. I'm not sure what I'll discover. @hayes may also have some ideas, since he expanded a bunch on my...

The EventEmitter leak seems to not be a problem with async-listener at all, it seems to originate from tap. Specifically, this line: https://github.com/isaacs/node-tap/blob/master/lib/tap-assert.js#L55 It surfaces when tap tries to use...

This hasn't been maintained for years. Why are you still using it when the functionality has been in Node.js core for several years now? 🤔

Supertest doesn't use async-listener. Somewhere else in your dependency graph something is still using this module when it shouldn't.

CLS is universally just trying to link async barriers to form that context though, so whether it is async_hooks, AsyncListener, or the monkey patches provided in the async-listener abstraction, they...

I don't think a complete polyfill of async_hooks is possible. It'd have to be slightly abstract to reduce it to only the parts of async_hooks that are actually reproduce-able in...

It's a queueing problem. You get that with user-mode queueing/pooling mechanisms. You'll need to patch the function before it enters the queue/pool. Try this: ``` js var addQueue = mongoose.Collection.prototype.addQueue...

CLS itself only focuses on supporting node core. There are various plugins to patch some userland modules which break due to queueing/pooling: https://www.npmjs.com/browse/keyword/continuation-local-storage Sadly, there's not really a reliable way...

`bindEmitter` only ensures continuation through event emitters. It doesn't _expose_ anything to the context. What you need is to do something like `session.set('request', req)` and then `session.get('request')` later.