v0.12.0 → v0.13.0

This guide covers behavior changes in the @outputai/core worker and in @outputai/llm cost reporting. Nothing in your code needs to change, but four runtime behaviors differ: the worker now bounds its own shutdown, every way it can end now has a defined outcome and exit code, a worker refuses to start unless it can publish a catalog matching its own source code, and LLM costs fall back to a bundled pricing snapshot instead of coming back empty.

Worker shutdown is now bounded

TEMPORAL_SHUTDOWN_GRACE_TIME and TEMPORAL_SHUTDOWN_FORCE_TIME have defaults, and the previously hardcoded hook flush allowance is now OUTPUT_HOOK_FLUSH_TIMEOUT_MS:

Variable	v0.12.0	v0.13.0	Meaning
`TEMPORAL_SHUTDOWN_GRACE_TIME`	unset (Temporal default `0`)	`15s`	How long in-flight activities run before they are asked to cancel
`TEMPORAL_SHUTDOWN_FORCE_TIME`	unset (no force termination)	`20s`	How long the worker drains before it gives up and terminates
`OUTPUT_HOOK_FLUSH_TIMEOUT_MS`	hardcoded `30000`	`5000`	How long pending hook callbacks are awaited once the drain is over

Previously the worker never force-terminated: it waited indefinitely for in-flight activities and was stopped only when the platform sent SIGKILL, which meant the hook flush was never reached at all on a deploy that caught in-flight work. It now stops draining after 20s and exits under its own control with code 1 - closing its Temporal connection, flushing hooks, and logging first. For most projects this is an improvement, because activities get 15 seconds of runway instead of being asked to cancel the instant a deploy starts, and buffered hook data actually gets written.

The three values are one budget

The drain runs to TEMPORAL_SHUTDOWN_FORCE_TIME and only then does the flush start, so the worst-case shutdown is force time plus flush timeout. That total has to fit inside the window your platform allows between SIGTERM and SIGKILL. The defaults total 25 seconds against the 30 seconds most platforms allow, leaving 5 seconds of margin. The hook flush is the part to watch when retuning. It used to be 30 seconds, which on a default platform window could not complete; it is now 5 seconds, which fits. Five seconds is ample for handlers that write to stdout or an in-process buffer, which is what hook handlers should be doing - they all share this one budget, so a single handler awaiting remote I/O spends the allowance the others need. If you do have a handler that must await a network round trip, batch it and raise both this value and your platform’s window, in that order.

Set the values explicitly if your activities drain slowly

If your activities routinely run longer than 20 seconds and you raised your platform’s shutdown window to accommodate them, set the variables explicitly. Otherwise those activities are cancelled at 15 seconds and abandoned at 20 on every deploy, then retried on the new instance. Keep grace below force, and force plus flush below your platform’s shutdown window, so the worker always exits before it is killed:

# Platform allows 300s between SIGTERM and SIGKILL
TEMPORAL_SHUTDOWN_GRACE_TIME=280s
TEMPORAL_SHUTDOWN_FORCE_TIME=285s
OUTPUT_HOOK_FLUSH_TIMEOUT_MS=10000

Values above your platform’s window never take effect, since the platform terminates the process first. On Render that window is maxShutdownDelaySeconds, which defaults to 30 seconds and can be raised to 300. On Kubernetes it is terminationGracePeriodSeconds. Raising these only extends shutdowns started by a signal. When an uncaught exception or unhandled rejection starts the shutdown instead, the worker force quits 60 seconds later regardless of TEMPORAL_SHUTDOWN_FORCE_TIME, exiting 1 after logging Uncaught exception handling timed out, force quitting.... That cap is fixed, so a force time above 60 seconds only fully applies to signal shutdowns. An empty value falls back to the default rather than disabling the bound, so there is no longer a way to configure an unbounded drain.

Shutdown scenarios

Every path that ends the worker changed shape. The exit code is also explicit now: v0.12.0 only called process.exit on the failure path and let the event loop empty on the success path.

Scenario	v0.12.0	v0.13.0
`SIGTERM`, `SIGINT` or `SIGUSR2` while polling	Stops polling and asks in-flight activities to cancel at once, then waits for them for as long as they take. Exits `0`	Stops polling and lets in-flight activities run for `TEMPORAL_SHUTDOWN_GRACE_TIME` before asking them to cancel. Exits `0`
In-flight work outlives the drain	Nothing bounds it, so the worker waits until the platform sends `SIGKILL` and the hook flush is never reached. Exit code is whatever the platform reports	Stops draining at `TEMPORAL_SHUTDOWN_FORCE_TIME`, warns with `Stopping Worker error`, flushes hooks. Exits `1`
A signal during startup	No handler was installed until the worker had been built, so the process died on the spot with no teardown and no hook flush. Exits `128 + signal number`, `143` for `SIGTERM`	The handler is installed first, so startup stops at the next step, services are torn down and hooks flush. Exits `0`
A second signal, more than a second after the first	Force quits on the spot, abandoning the drain. Exits `1`	Unchanged
A service other than the worker fails to stop	Warns and carries on with the rest of the teardown. Exit code unaffected	Unchanged
Uncaught exception or unhandled rejection	Not handled, so Node printed the stack and terminated immediately: no drain, no hook flush, no `onError` hook. Exits `1`	Drains exactly like a signal, emits `RUNTIME_ERROR` so `onError` hooks fire, flushes hooks. Exits `1`
An uncaught error whose drain stalls	Not applicable, there was no drain	Force quits 60 seconds after the error. Exits `1`
The Temporal connection is lost	Drains, then reports the loss. Exits `1`	Unchanged
The worker fails to stop	Drains what it can, then reports the failure. Exits `1`	Unchanged
The catalog cannot be published	The catalog ran alongside the worker, so the worker was already polling against a stale catalog when the failure surfaced. Exits `1`	The catalog gates the worker: it retries twice and never starts polling. Exits `1`
Startup fails to load, bundle or connect	Tears down whatever was built. Exits `1`	Unchanged

If you alert on non-zero worker exits, the situations that produce one changed. A drain that outlives its window is now one of them, where v0.12.0 hung until the platform stepped in, so expect an exit 1 from any deploy that lands on work longer than TEMPORAL_SHUTDOWN_FORCE_TIME. Nothing in the logs separates it from another failure to stop: the Stopping Worker error warning reports IllegalStateError: Worker still in use, because the forced termination leaves in-flight polls behind, and Temporal’s own Worker failed line serializes its error as empty. Treat a non-zero exit on a deploy you triggered as routine. An uncaught error still exits 1, but now only after draining. Two log lines moved with this. The failure log is now Worker error rather than Fatal error, and the last line is always Bye, where a failing worker used to end on Exiting....

Workers exit when the catalog does not match

The worker publishes its catalog during startup and treats it as a gate. If it cannot publish a catalog matching its own source code, it retries twice and then exits rather than serving requests against an outdated catalog. A worker that would previously have started with a stale catalog now fails its deploy instead. The failure is logged as Worker error with the underlying Temporal error. Reconciliation also changed: a stale catalog workflow is now terminated rather than asked to complete. A catalog that stopped processing workflow tasks no longer blocks every deploy that follows it.

LLM cost survives a pricing outage

@outputai/llm now ships a snapshot of the pricing table. When the live catalog is unreachable and nothing is cached, costs are calculated from that snapshot instead of coming back as null, and are reported with status: "imprecise" and pricingFreshness: "snapshot". If you branch on cost === null to skip cost accounting during an outage, that branch stops firing and you start recording snapshot-derived figures instead. Check pricingFreshness or status for that case. cost is still null when usage cannot be normalized, and a provider or model missing from the table still produces a non-null, incomplete cost.

Checklist

Set TEMPORAL_SHUTDOWN_GRACE_TIME, TEMPORAL_SHUTDOWN_FORCE_TIME and OUTPUT_HOOK_FLUSH_TIMEOUT_MS explicitly if your activities need more than 20 seconds to drain, keeping force time plus flush timeout under your platform’s shutdown window.
Raise OUTPUT_HOOK_FLUSH_TIMEOUT_MS if your hook callbacks do real I/O, since the allowance dropped from a hardcoded 30 seconds to 5.
Update alerts that key off worker exits or the Fatal error log line, which is now Worker error.
Expect a worker whose catalog cannot be published to exit instead of starting with a stale catalog.
Replace any cost === null check used to detect a pricing outage with a pricingFreshness or status check.

Start Here

Workflows

Steps

Prompts

Clients

Costs

Evaluators

Production Readiness

Deployment

Integrate with Your App

Packages

Releases

Worker shutdown is now bounded

The three values are one budget

Set the values explicitly if your activities drain slowly

Shutdown scenarios

Workers exit when the catalog does not match

LLM cost survives a pricing outage

Checklist

​Worker shutdown is now bounded

​The three values are one budget

​Set the values explicitly if your activities drain slowly

​Shutdown scenarios

​Workers exit when the catalog does not match

​LLM cost survives a pricing outage

​Checklist

Worker shutdown is now bounded

The three values are one budget

Set the values explicitly if your activities drain slowly

Shutdown scenarios

Workers exit when the catalog does not match

LLM cost survives a pricing outage

Checklist