feat(rivetkit): forward otel sdk warnings to the pino logger

[eersnington]

sends otel sdk warnings and errors from core to the actor's pino logger. also handles for warns and errors. also is safe as it will release the logging callback on shutdown so it doesn't keep node running

[eersnington]

Stack for rivet-dev/actors

• #5734 docs(rivetkit): add actor tracing docs
• #5733 feat(rivetkit): forward otel sdk warnings to the pino logger 👈
• #5732 feat(rivetkit): trace actor to actor calls
• #5730 feat(rivetkit-core): trace queue sends and receives
• #5731 feat(rivetkit-core): trace raw http requests
• #5729 feat(rivetkit-core): trace scheduled invocations
• #5726 feat(rivetkit): send trace context from clients
• #5723 feat(rivetkit): pass trace context to js and logs
• #5727 feat(rivetkit): trace sqlite operations
• #5721 feat(rivetkit): trace actor invocations
• #5728 fix(pegboard-gateway): forward request ray id to actors
• #5724 test(rivetkit): let driver runtimes take extra environment
• #5722 fix(rivetkit): disable services in driver test runtimes
• main

Get stack: forklift get 5733
Push local edits: forklift submit
Merge when ready: forklift merge 5733

_{change vmosovzz}

[the-company-company]

🟠 1 medium-severity finding

_{Reviewed commit a550f80.}

[the-company-company]

✅ No issues found

_{Reviewed commit e34c47e.}

[claude]

Review: forward OTel SDK warnings + workflow run/step tracing

Large but well-organized change (Rust core telemetry, NAPI bridge, TS runtime/workflow-engine, docs). The design follows the existing invocation/span patterns in telemetry.rs closely (link-not-parent for new traces, Drop-as-abandoned semantics, versioned BARE storage for the persisted run context), and test coverage for the new workflow spans is thorough (chaining across sleeps, ray propagation, retried-step attempts, nested SQL/queue spans).

A couple of things worth a look before merge:

1. finally { await span.finish(outcome) } can mask the real workflow result/error

rivetkit-typescript/packages/workflow-engine/src/index.ts (traceRun, ~line 923-944):

```ts
try {
const result = await span.run(() => run(span));
outcome = runOutcomeFromState(result.state);
return result;
} catch (error) {
if (error instanceof EvictedError) outcome = "cancelled";
throw error;
} finally {
await span.finish(outcome);
}
```

If span.finish(outcome) throws (NAPI bridge exception, native panic bridged as a JS error, etc.), that exception replaces whatever the try/catch was about to return or throw, including a legitimate workflow failure or a successful result. The rest of the codebase treats telemetry as strictly best-effort (WorkflowRunInvocation::finish/finish_workflow_span in Rust already swallow persistence errors with tracing::warn!, and the docs state "Export ... never fails actor work"), so this call site is the odd one out. In practice WorkflowRunOutcome::parse only fails on a bad string, which shouldn't happen given the TS union type, so the risk is narrow, but a finally that awaits something fallible is worth guarding (e.g. wrap span.finish in try/catch + log) so a telemetry-layer hiccup can never override the actual workflow outcome.

2. Process-wide SDK log sink vs. per-registry lifecycle

rivetkit-typescript/packages/rivetkit-napi/src/telemetry.rs keeps the sink in a single global static SINK, and rivetkit-typescript/packages/rivetkit/src/registry/napi-runtime.ts calls setTelemetryLogSink(...) on every createRegistry() while shutdownTelemetry() is invoked per-runtime on registry shutdown (registry/index.ts: [...runtimes].map(r => r.shutdownTelemetry?.())). Since the sink is process-wide by design (per the comment in telemetry.rs), if a single Node process ever hosts more than one registry concurrently:

• the later createRegistry() call's sink silently replaces the earlier one, so SDK warnings from the first registry's actors get attributed to the second registry's logger, and
• stopping any one registry uninstalls the sink for all the others still running, which silently falls back to raw Rust log formatting for their SDK warnings.

This is diagnostics-only (doesn't affect actor behavior) and may just be an accepted limitation of "one telemetry pipeline per process," but it's worth confirming that's the intended deployment model, or noting the caveat in docs-internal/engine/rivetkit-telemetry.md.

Everything else looked solid

• telemetry.rs: ray-id handling correctly moved from an immutable inner.ray_id to a lock-guarded state.ray_id everywhere (no stale direct reads remain), and start_queue_receive's workflow-takes-message-ray logic matches the documented "a workflow run takes the ray of each queue message it receives" behavior.
• WorkflowTraceContextV1/key reservation (rivetkit-core::keys::WORKFLOW_TRACE_CONTEXT_KEY = tuple-encoded 5, matching the // 5 is reserved for RivetKit's workflow trace context comment in workflow-engine/src/keys.ts) is a correctly cross-referenced, non-colliding reservation in the shared _rivet_wf_kv table.
• New versioned struct follows the existing RunWakeAt/LastPushedAlarm pattern exactly (manual match on version, empty converters vec), compliant with the "never round-trip serialize/deserialize for version converters" rule.
• runOutcomeFromState/WorkflowRunOutcome/WorkflowStepOutcome matches are exhaustive (no _ fallthrough on enums), per CLAUDE.md.
• The "EvictedError only on cancellation" comment in traceRun checks out: executeWorkflow's only unhandled EvictedError rethrow is the storage.state === "cancelled" check; the graceful evict() path is fully absorbed into setEvictedState and returned as a normal result, so it never hits that catch.
• New sql_efficiency.rs case for _rivet_wf_kv lookups follows the required test-coverage policy for new internal SQL queries.
• vi.waitFor calls in actor-telemetry.test.ts all carry the required adjacent justification comment.

No security concerns; the data policy section explicitly excludes SQL text/bindings/state/raw error messages from spans, and the new attributes (rivet.workflow.run.outcome, rivet.workflow.step.*) are all bounded enum-like values, consistent with the metrics cardinality rules.