level filter not work for transports

[Viiprogrammer]

How to reproduce:

import pino from 'pino'

const transports = pino.transport({
  targets: [{
      level: 'error',
      target: 'pino/file',
      options: {
        destination: '1' //stdout
      }
  }]
})

const logger = pino({}, transports)

logger.debug('Debug')
logger.info('Info')
logger.warn('Warn')
logger.error('Error')

Expected behavior:

node test 

{"level":50,"time":1719528510555,"pid":47437,"hostname":"anime-desktop","msg":"Error"}

Actual behavior:

node test 

{"level":30,"time":1719528510555,"pid":47437,"hostname":"anime-desktop","msg":"Info"}
{"level":40,"time":1719528510555,"pid":47437,"hostname":"anime-desktop","msg":"Warn"}
{"level":50,"time":1719528510555,"pid":47437,"hostname":"anime-desktop","msg":"Error"}

Same for any other transports

Version: 9.2.0
Node.js version: 18.20.3

[chernodub]

Hi @Viiprogrammer, try using dedupe flag — it should help

I believe this happens because of the nature of the log levels. Each level by design includes those that are greater (e.g. info includes error, etc). As far as I understand, they were not intended to be used as channel/transport switches.

---

@mcollina it would probably make sense to architect such a feature — to be able to use a specific transport/channel for each log call.

As an initial draft for the API:

const logger = pino({
  transport: {
    targets: [
      { target: 'pino/file', options: { destination: 1 }, id: "stdout" },
      { target: './customRemoteStream.ts, id: "remote" }
    ]
  }
});

logger.transports.stdout.info('...');
logger.transports.remote.info('...');

[fabulousgk]

Confirming this is new behavior since 9.0.0 and is not in line with the transports documentation. If I set level: 'error' on a target I should only get errors, if is set level: 'warn' I would get warn and errors. As it stands the level setting seems to be ignored atm.

[fabulousgk]

I played around and determined this behavior change occurred with the 9.1.0 release. Figuring out the rest is beyond my skill.

Is this something that will be fixed? I can revert to 9.0.0 for now if there is no workaround, but that is only viable if the functionality will come back in a future release. If not...not sure what I am going to do TBH.

[fabulousgk]

This is still an issue in 9.4. I am not sure the behavior is exactly the same, though. As of 9.4, when 2 targets are configured, levels work as expected; however, if only 1 is configured, the target level is ignored.

[mcollina]

Thanks for reporting! Would you like to send a Pull Request to address this issue? Remember to add unit tests.