Internal errors in @axiomhq/pino cause server to crash

TL;DR

For "Error FetchClient.[anonymous] ... Service Unavailable": wrapping with pino hooks did not help because ingest's promise is not returned by the log function.

Error FetchClient.[anonymous] ... Service Unavailable

Steps

1. Using @axiomhq/pino in Koa Node servers: during an hour-long Axiom ingestion outage, unhandled network errors thrown from axiom.ingest crashed the servers (Sentry showed Error FetchClient.[anonymous] ... Service Unavailable thrown at the program root). The same crash happens with an expired or invalid API token. Wrapping with pino hooks did not help because ingest's promise is not returned by the log function.
2. What actually fixes it (verified in the thread):
3. The SDK did not catch network errors from ingest, so any ingestion failure (outage, expired/invalid token) became an uncaught exception that took down the process. Maintainers released new versions of @axiomhq/js and @axiomhq/pino that catch ingestion exceptions internally (surfacing them via console.error instead of crashing) and added an onError() handler to the js SDK for routing errors to your own handler. Upgrade both packages. One caveat from the thread: the onError option is supported on the js SDK; pino runs its transport in a worker thread where passing a function callback through postMessage is not possible, so pino-side errors surface via console logging for now.

When to use

You are seeing this: The situation: Using @axiomhq/pino in Koa Node servers: during an hour-long Axiom ingestion outage, unhandled network errors thrown from axiom.ingest crashed the servers (Sentry showed Error FetchClient.[anonymous]... Use this skill when you run into "Internal errors in @axiomhq/pino cause server to crash".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Edge cases

• One caveat from the thread: the onError option is supported on the js SDK; pino runs its transport in a worker thread where passing a function callback through postMessage is not possible, so pino-side errors surface via console logging for now.

Someone asked: Using @axiomhq/pino in Koa Node servers: during an hour-long Axiom ingestion outage, unhandled network errors thrown from axiom.ingest crashed the servers (Sentry showed Error FetchClient.[anonymous] ... Service Unavailable thrown at the program root). The same crash happens with an expired or invalid API token. Wrapping with pino hooks did not help because ingest's promise is not returned by the log function. The verified answer: The SDK did not catch network errors from ingest, so any ingestion failure (outage, expired/invalid token) became an uncaught exception that took down the process. Maintainers released new versions of @axiomhq/js and @axiomhq/pino that catch ingestion exceptions internally (surfacing them via console.error instead of crashing) and added an onError() handler to the js SDK for routing errors to your own handler. Upgrade both packages. One caveat from the thread: the onError option is supported on the js SDK; pino runs its transport in a worker thread where passing a function callback through postMessage is not possible, so pino-side errors surface via console logging for now. Full thread: https://vectle.com/threads/thr_Uj6jiKhbSr47cDJ9Rrm15g