[PetrHeinz]

A Pino transport runs in Pino's worker thread, so a serverless handler cannot wait for its logs. pino.flush() only moves the main thread's buffer into the worker, and the worker's batch and HTTP request freeze with the function (#112).

@logtail/pino now also exports LogtailStream, an in-process Pino destination that logs through a @logtail/node client the application owns:

const logtail = new Logtail("$SOURCE_TOKEN");
const logger = pino(new LogtailStream(logtail));
// at the end of the handler
await logtail.flush(); // or logger.flush(callback)

• It uses the same mapping as the worker transport (levels, custom level names, messageKey, message_field, Pino's time), in a helper shared by both. Pino 8.21+ shares its level names and message key with the stream through its configuration message; the customLevels option covers older Pino.
• Lines are handled synchronously in _write, so a flush right after a log call covers that log.
• logger.flush() calls the stream's flush(callback), which flushes the client. Ending the stream flushes it too.
• context.runtime points at the caller, including for custom-level methods.
• Lines that are not JSON are skipped, as the worker transport does.
• A failed send does not become an unhandled rejection; it is counted in logtail.dropped. With throwExceptions there is no caller to throw to, and printing the error would get it forwarded again by replaceConsoleMethods().

Two fixes in the shared mapping apply to the worker transport too:

• pino({ timestamp: false }) no longer throws; it used to kill the worker silently.
• dt is the time Pino logged, also for its default epoch milliseconds; before, it was the processing time. A numeric time below 1e11 is read as epoch seconds (pino.stdTimeFunctions.unixTime).

@logtail/node's flush() now also waits for sends already in flight, such as a batch the 1 s timer had already started, so everything logged before the call has been sent when it resolves. If one of those sends fails, it flushes once more, so the logs the batcher put back go out before it resolves. Core keeps the started sends until they settle. Browser and Edge flush as before.

This is patch-level:

• No options change.
• The stream gains flush(callback).
• Node's flush() resolves later only while an earlier send is still running or being resent, which is bounded by timeout and retryCount.

Verified against Better Stack on Node 20, 22 and 26 and Pino 8.16 to 10.3, with a harness that freezes the process the moment the handler resolves, as Lambda does:

• Stream + await logtail.flush(): 16 of 16 lines delivered before the freeze, also with a 1.5 s handler whose timer batch is still in flight. The worker transport delivers 2 of 16, with or without logger.flush().
• Stream + logger.flush(): 16 of 16.
• throwExceptions with a revoked token: the process keeps running; before, it died with an unhandled rejection.
• A send in flight that fails, followed by an immediate exit: 5 of 5 delivered through the resend.

Each fix commit is preceded by a tests-only commit that is expected to fail CI.

Docs: the Pino page needs a "Serverless" section showing the stream and await logtail.flush().

🤖 Generated with Claude Code