pino-http: customProps causes TypeError: logger[stringifySym] is not a function

customProps option is causing application to crash with

TypeError: logger[stringifySym] is not a function
  /Users/xxxx/node_modules/pino-http/logger.js:106
  const customPropBindingStr = logger[stringifySym](customPropBindings).replace(/[{}]/g, '')

After doing some debugging, seems that pino.child(bindings) call returns child logger which doesn’t contain most of the symbols, including Symbol(pino.stringify).

You can see this by:

const logger = pino(pinoOptions);
console.log({logger})
const child = logger.child({});
console.log({child})

Internally pino-http does create child logger and stringify symbol is expected to be included later in the logger (https://github.com/pinojs/pino-http/blob/master/logger.js#L106)

 if (customPropBindings) {
      const customPropBindingStr = logger[stringifySym](customPropBindings).replace(/[{}]/g, '')
      const customPropBindingsStr = logger[chindingsSym]
      if (!customPropBindingsStr.includes(customPropBindingStr)) {
        log = logger.child(customPropBindings)
      }
    }

I was testing with pino 8.16.2 and pino-http 8.5.1

About this issue

Original URL
State: open
Created 7 months ago
Comments: 15 (3 by maintainers)

Most upvoted comments

Yes, this is on purpose.

Right. We’re in the pino-http repo here. The bug is in #288 using these symbols to reference props set in another realm, not in pino for choosing to export unique symbols. If pino-http used these imported symbols to set props and then access them, all would be fine. Instead it is accessing props with a Symbol that it has no guarantee exists on the obj. pino-http is a separate package that interacts with pino through exports …

I think the solution to this bug is to support an optional parameter that allows a user to override the version of pino that it needs to be using.

If you take a detailed look at the repro, there is only one version of pino. We’re in the same runtime. It’s not like we’re instantiating pino in another instance of node and expecting to somehow RPC over to it. We’re in the same process, same address space, same bits on disk. How do you even see that (‘choosing which pino’) working? We only import one.

nuzayets on Jan 17, 2024

stringifySym and chindingsSym as used by #288 are not created with Symbol.for in pino.

Yes, this is on purpose.

So, if you are in a monorepo with the logger instantiated in a different package (even with the same version of pino)

Essentially, you are flagging a bug in your monorepo software 😉.

mcollina on Jan 17, 2024

I had been using pino@v8.19.0 and pino-http@v9.0.0 for a while without any issues and started experiencing this after bumping to pino@v9.0.0. I’m not entirely sure I understand why the previous combination of versions worked (since the proposed solution here is to pin pino-http on an older version). I’m resorting to pinning pino to the old version for now.

fuadsaud on Apr 30, 2024

@nuzayets I am facing the same issue. Were you able to figure out a workaround ?

saisantosh on Feb 22, 2024

I’m using pino with nestjs. Upgrade to 8.6.0 solved the issue on my end. 🤷‍♂️

alexkorsun on Dec 20, 2023