feat(rivetkit): pass trace context to js and logs

[eersnington]

• Making the current action's trace available in JS so application spans can sit under it
• Adding actor, ray and trace IDs to actor logs, and passing trace context through actor clients
• Keeping the action span open until its waitUntil work finishes

[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 5723
Push local edits: forklift submit
Merge when ready: forklift merge 5723

_{change lpqzmttt}

[the-company-company]

🟠 1 medium-severity finding

_{Reviewed commit 6a1b670.}

[the-company-company]

🟠 Medium · Resolve trace context through the active invocation

actorInvocationTraceContext reads the context captured when the client was created, rather than the invocation in #invocationContext. A client can be retained in actor state/vars (or captured by run) and used during a later action; its captured context has already finished, so this returns undefined and the actor-to-actor request drops both trace headers and the ray ID.

This runtime already resolves SQLite operations through #actorContextForOperation for this exact retained-handle case. Use that resolver before reading invocationTraceContext() so a same-instance active action supplies its current context.

[claude]

Code Review

Re-reviewed against the current diff (updated 2026-09-22, HEAD 561a425c). This supersedes the previous pass. Findings below were re-verified against the current code; several carry over unchanged, others are new.

Findings

1. rivetkit-rust/packages/rivetkit-core/src/telemetry.rs:336-345 (finish_with) - Unconditionally logs "reply sent" whenever pending_work > 0, even though this helper is shared by both finish() (line 325, the real success/error path) and finish_dropped() (line 329, the abandoned-reply path used when an ActionInvocationSpan is dropped without a reply, e.g. actor force-stopped mid-flight). finish_dropped() correctly marks otel.status_code = ERROR / error.type = actor.dropped_reply, but if a wait_until task is still holding pending_work > 0 at that point, the exported trace/log also claims "reply sent", which is actively misleading during an abort investigation since no reply was ever sent on that path.

2. rivetkit-typescript/packages/rivetkit/src/engine-client/actor-http-client.ts:61-72 (buildGuardHeaders) - The traceparent/tracestate loop explicitly does headers.delete(name) before conditionally re-setting from the real request, so a value statically configured in runConfig.headers can never leak through (per the comment: "Configured trace context is never sent: it would pin every call to one span"). The x-rivet-ray-id block directly below has no equivalent headers.delete(HEADER_RIVET_RAY_ID); it only does if (requestRayId !== null) headers.set(...). If runConfig.headers ever contains a static x-rivet-ray-id and the incoming request carries no ray ID of its own, that stale value survives untouched into the outgoing gateway request, pinning every such call to one ray ID, the exact failure mode the header above was written to avoid.

3. rivetkit-typescript/packages/rivetkit/src/client/actor-handle.ts - Trace/ray-id propagation is wired into exactly one outgoing path: #sendActionNow (~line 331), via #currentActorInvocation and actorInvocationTraceHeaders. #sendQueueMessage (line 147) and #fetchWithResolvedActor (line 682, backing the raw .fetch()/.websocket() client surface) never read #currentActorInvocation and never set any trace/ray headers. An actor calling another actor via c.client.b.getOrCreate().queue.send(...) or .fetch(...) mid-invocation silently starts a brand-new, uncorrelated trace on the callee, while the same call via .someAction() propagates correctly. This is inconsistent behavior depending on call shape, for a PR whose stated goal is passing trace context through actor clients generally.

4. rivetkit-typescript/packages/rivetkit/src/registry/wasm-runtime.ts:546-550 - actorInvocationTraceContext(_ctx) is a hardcoded return undefined, with no attempt to forward to rivetkit-core. rivetkit-typescript/CLAUDE.md states: "Wasm bindings for NAPI-supported runtime APIs should forward to rivetkit-core; avoid placeholder returns that break runtime parity." As written, every wasm-hosted actor gets zero trace/ray-id correlation for c.log and actor-to-actor clients, silently diverging from the NAPI runtime for this new capability.

5. rivetkit-typescript/packages/rivetkit/src/registry/runtime.ts:550-557 - The new doc comment on runWithActorInvocationContext says "Only actions, raw requests, and queue dispatch run this way." In registry/native.ts, runtime.runWithActorInvocationContext(...) is only ever called from the actions: handler map (line 5362); the onRequest (line 5053) and onQueueSend (line 5370) handlers never call it. A reader relying on the comment would wrongly assume raw HTTP requests and queue dispatch get an active invocation span or c.log correlation. They currently do not, which also underlines finding [SVC-2504] Fix 5 GB upload limit for local development from Cloudflare #3 above.

Minor / lower confidence

• rivetkit-rust/packages/rivetkit-core/src/actor/context.rs:763-789 - the native and wasm wait_until variants duplicate the identical hold_open + drop(invocation) wrapper verbatim across the two #[cfg] branches (only the Send bound differs, matching the existing pattern for register_task/spawn_work in this file). Low-impact, but a future change to hold-open semantics needs to be kept in sync by hand in both places.
• rivetkit-typescript/packages/rivetkit/src/client/actor-handle.ts:331 - #currentActorInvocation?.() is invoked inside #sendActionNows retry loop, so a call that retries several times on overload re-fetches trace context from the NAPI side on every attempt even though it cannot change mid-invocation. Likely negligible relative to actor I/O latency, but easy to hoist above the loop if it shows up in profiling.

Test coverage

• No focused test (TS or Rust) covers the dropped-reply mislabeling in finding [SVC-2555] Set up issue templates #1, the ray-id static-config leak in finding [SVC-2479] Send cluster events to PostHog #2, or the queue-send/raw-fetch propagation gap in finding [SVC-2504] Fix 5 GB upload limit for local development from Cloudflare #3. The existing actor-telemetry.test.ts / fixtures/driver-test-suite/telemetry.ts coverage exercises the .action() happy path only.

Notes

• No other CLAUDE.md convention violations spotted (comment style, structured logging, parking_lot::Mutex usage in Drop/sync paths, exhaustive enum matches all match repo conventions in this diff).

🤖 Generated with Claude Code

[the-company-company]

🟠 1 medium-severity finding

_{Reviewed commit 483d6f1.}

[the-company-company]

🟠 Medium · Resolve trace context through the active invocation

actorInvocationTraceContext reads the context captured when the client was created, rather than the invocation in #invocationContext. A client can be retained in actor state/vars (or captured by run) and used during a later action; its captured context has already finished, so this returns undefined and the actor-to-actor request drops both trace headers and the ray ID.

This runtime already resolves SQLite operations through #actorContextForOperation for this exact retained-handle case. Use that resolver before reading invocationTraceContext() so a same-instance active action supplies its current context.

[eersnington]

No test verifies ctx.log is enriched with rayId/traceId/spanId

followed up in #5732, including overlapping invocations

No test verifies ActorHandleRaw/sendHttpRequestToGateway actually forwards traceparent/tracestate/x-rivet-ray-id on an actor-to-actor call

followed up in #5726 and #5732

No unit tests for the new pure helpers in otel-context.ts

my clank in christ, you really love this don't you

covering hold_open/finish/guard-drop ordering

the waitUntil driver test checks the exported span's lifetime

This is safe today because every ActorContextHandleAdapter/conn-context instance is freshly constructed per dispatch

yeah ig?

[the-company-company]

🟠 1 medium-severity finding

_{Reviewed commit 08b79f2.}

[the-company-company]

🟠 Medium · Resolve trace context through the active invocation

actorInvocationTraceContext reads the context captured when the client was created, rather than the invocation in #invocationContext. A client can be retained in actor state/vars (or captured by run) and used during a later action; its captured context has already finished, so this returns undefined and the actor-to-actor request drops both trace headers and the ray ID.

This runtime already resolves SQLite operations through #actorContextForOperation for this exact retained-handle case. Use that resolver before reading invocationTraceContext() so a same-instance active action supplies its current context.

[the-company-company]

✅ No issues found

_{Reviewed commit 58dfd19.}