Pino-socket blocks other transports when TCP server is not available at start

[brjakab]

Given this snippet:

const transport = pino.transport({
  targets: [
    {
      target: 'pino-pretty',
      level: 'debug',
    },
    {
      target: 'pino-socket',
      level: 'debug',
      options: {
        address: 'localhost',
        port: '10000',
        mode: 'tcp',
        reconnect: false,
      },
    },
  ],
});

const logger = pino(
  {
    level: 'debug',
    name: 'pino-socket-test',
    timestamp: pino.stdTimeFunctions.isoTime,
  },
  transport,
);

logger.info('first log');

setInterval(() => {
  logger.info('interval log');
}, 5 * 1000);

If my TCP server is running on localhost port 10000, all is working correctly.

Problem:

1. But if I stop the server and then run this script, then I get this error in the console:

Error: the worker has exited

And my script exists.

2. If I set reconnecting to true instead, my script just hangs and never logs anything.

Solution:

If I remove the wait for the connection to open:

pino-socket/lib/pino-transport.js

Line 36 in 903f790

await once(connection, 'open')

Then other transports, in this case pino-pretty, can start logging in both cases, and no error occurs.

Can this be removed or at least be configurable?

[jsumners]

A TCP destination needs an open connection to work. I recommend using UDP if you are looking for a fire and forget configuration.

[brjakab]

I understand. My problem is that if I have a TCP destination among many other destinations, then all the other destinations are blocked until the TCP connection is established for the first time.

Let's say I have these destinations: pino-roll, pino-loki, pino-pretty and pino-socket. I set pino-socket to TCP and reconnect to true, then I start my application. Let's say that at this time, my TCP server is unavailable. This will cause pino-socket to try and reconnect, as expected. However I don't know if it's expected behavior that in this case, all the other destinations won't receive any data, until the TCP connection is successfully established .

On the other hand, if my TCP server is available when I start the app, then all the other destinations will work as expected, even when the TCP connection is lost: pino-socket will retry, and the other destinations will continue to work even when the TCP server is down.

[mcollina]

There are two problems we need to mitigate here:

• log loss if a destination if not available
• program crashing if a destination among many is not available
• memory leaks if a destination is not available (we can't keep buffering all data in memory)

I fear most of those problems should be addressed in pino itself.