Should EventEmitter extend AsyncResource?

[ronag]

Would simplify some things and make it more ergonomic to ensure async context propagation in various API's. Though probably with some performance impact?

[devsnek]

I'm not an expert, but events are dispatched synchronously. So if you emit an event in some async code, the context should already be correct?

[ronag]

Not at all. Depends on what the root of the event is. e.g. most stream events would need a runinasynccontext when backed by e.g. a socket.

Do fs methods properly propagate async context?

[addaleax]

I think this generally makes sense, for the same reason that the domain module, in addition to tracking async context, also monkey-patched the EventEmitter class to provide for this.

Also, just for context, there is some previous discussion in #33723.

[devsnek]

oh is this about propagating the context that was active when the emitter instance was created?

[addaleax]

That’s a valid question. Either we propagate the context of when the emitter was created, or the context of when the listener was registered.

My understanding of how async_hooks works, and my understanding of what makes sense here for e.g. ALS, would be to use the async id of the listener registration, but the async trigger id of the emitter creation. In particular, for this:

http.createServer((req, res) => {
  asyncLocalStorage.run(store, () => {
    req.on('end', () => {
      const store = asyncLocalStorage.getStore();  
    });
  });
}).listen(8080);

I think it would be a common expectation that the inner store variable matches the outer one.

[ronag]

async id of the listener registration, but the async trigger id of the emitter creation

This has always confused me. What is the practical difference of these two? i.e. how would I consume them differently?

[addaleax]

@ronag My understanding is that the async id propagates the when of an async call, and the trigger async id propagates the why. I think we’re definitely lacking a clear definition that can be applied programatically here, though.

[kjarmicki]

@addaleax Could enterWith(store) be an answer here? Modifying your example:

http.createServer((req, res) => {
  asyncLocalStorage.enterWith(store);
  req.on('end', () => {
    const store = asyncLocalStorage.getStore();  
  });
}).listen(8080);

On v12.18.2 the store is still available in the callback.
As far as I understand enterWith, the store should not leak to other requests, so would there be any reason not to use it like that?

[addaleax]

@kjarmicki That might work in your case, but it probably only does so by accident – in order to actually consume the content of req, you’ll need to read from req or discard its contents using req.resume();, and at least as far as I can tell the deciding factor is whether the resume call happens inside the ALS scope or not. Event listeners don’t interact with ALS at all so far by themselves.

[kjarmicki]

@addaleax oh, ok 🙂

So the right way would be to wrap the end event with a Promise, correct?

http.createServer((req, res) => {
  asyncLocalStorage.run(store, () => {
    new Promise(resolve => req.on('end', resolve))
      .then(() => {
        const store = asyncLocalStorage.getStore();
      });
  });
}).listen(8080);

[addaleax]

@kjarmicki I’m not sure what you mean by “the right way”, but that should work (and using await events.once(req, 'end') would work as well). But this discussion here is specifically about whether EventEmitter should also propagate async context on its own.

[kjarmicki]

@addaleax by "the right way" I meant that it wouldn't be an accident that it works.
Thank you for the replies, and I'm not derailing the discussion anymore 😉

[ronag]

@ronag My understanding is that the async id propagates the when of an async call, and the trigger async id propagates the why. I think we’re definitely lacking a clear definition that can be applied programatically here, though.

That answers part of my question. Though I'm still unsure when & how I would practically use e.g. trigger id. I think some motivating examples in the doc would be nice in this case.

[jasnell]

Fwiw, I tried this once and performance of EventEmitter dropped tenfold. A better approach (albeit less ergonomic) would be to either emit from within the context you wish to propagate, or bind the handler function to it.