Question: Does the log.options work for concurrent requests

[ronkot]

I'm a bit confused of how setting invocation specific data to the global log.options works. Let's consider the following case:

1. Request 1 (R1) comes in
2. R1 sets the global log.options.meta.event = event; (event is specific to R1)
3. R1 makes some async call and control is given to event loop
4. Request 2 (R2) comes in
5. R2 sets the global log.options.meta.event = event; (here event is specific to R2)
6. R2 makes async call and control is given to event loop
7. R1 resumes to execution and makes a log.info('R1')call
8. --> The log row contains log message 'R1' but the meta.event is from R2 ?

Have I understood this correctly? To me it seems that we just cannot use global instance to set request specific stuff. Instead, we should create an own instance of logger for each request and pass the logger as function argument downstream.

EDIT: This case assumes that the same NodeJS instance is used to serve multiple requests. AFAIK this is how Lambda (and also e.g. Azure functions) works. If we had completely separate NodeJS instances for each call, we'd not have this problem.

[KyleRoss]

@ronkot What you have provided is correct in terms of how the global options would work although that wouldn't be the way you'd want to set metadata for a single log message. Each of the log methods has the ability to take in metadata to include with the log message. For example:

log.info('R1', { event });

The global options should be used to set values that do not change. You can set data within log.options.meta and that will be merged with any metadata that was to be passed in via a log method.

[ronkot]

Ah, I understand. Thanks for clarification :) I just got baffled when read the first code example in README.