Closed jsumners closed 3 years ago
The reason why this is not working is because console.log()
(and friends) in workers send the message to the main thread, which has its event loop shut down already because of process.exit(1)
.
Just use pino.destination()
and it would all work smoothly. In other terms, we should just document this.
If I modify stderr.mjs
to the following, I still see the same issue:
import { Writable } from "stream";
import pino from "pino";
const destination = pino.destination(2);
export default (options) => {
const myTransportStream = new Writable({
write(chunk, enc, cb) {
destination.write(chunk.toString());
cb();
},
});
return myTransportStream;
};
Are we saying that we simply cannot support a custom transport with hard exits?
What you are asking is an edge case that we are not handling atm. Essentially we should need at least one event loop spin to start the worker.
"use strict";
const pino = require(".");
const transport = pino.transport({
target: 'pino/file',
options: {
destination: 1
}
});
const log = pino(transport);
log.info("start");
transport.on('ready', function () {
log.error("boom");
// With the next line uncommented, no logs will be shown.
process.exit(1);
})
However this is not working either, so that's a regression.
I've found the regression for the latest case. The main one reported (no event loop spin) might require a bit more work however it's totally doable.
I thought we had implemented something around this. But I wasn't having any luck searching through the issues.
PR incoming for the latter case https://github.com/pinojs/pino/issues/1183#issuecomment-950940938
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
I'm not sure there is anything we can do about this except document it?
index.js:
stderr.mjs: