[eersnington]

A UserError whose metadata JSON cannot encode, such as a bigint, was replaced by a TypeError when it crossed from TypeScript into core.

throw new UserError("Card declined", {
	code: "card_declined",
	metadata: { amountCents: 1999n },
});

Where it is thrown	Before	After
action or run	client gets internal_error	client gets card_declined, without metadata
workflow step, tracing on	step fails without retrying	step retries
c.client() call, tracing on	caller gets the TypeError	caller gets the original error

• encodeBridgeRivetError encodes every structured error that crosses into core. When JSON.stringify throws, it encodes the error again without metadata and returns the cause as droppedMetadataCause.
• encodeNativeCallbackError logs a warning with the group, code, and cause when metadata was dropped. The span paths ignore it, because spans never read metadata.
• actor/errors.ts has no runtime imports, so rivetkit/errors bundles to 4.7 KB minified. Importing the logger there would pull in pino and zod and grow it to 304 KB.
• The errors docs say a UserError is returned to the client and only other errors become internal_error. This keeps that true for metadata JSON cannot encode.

---

This is part 1 of 3 in a stack:

•  3  feat(rivetkit): export actor spans from the rust sdk #5783
•  2  fix(rivetkit): rebuild the workflow logger when the run's ray changes #5781
•  1  fix(rivetkit): keep UserErrors intact when their metadata is not JSON #5782 👈

[eersnington]

Stack for rivet-dev/actors

• #5783 feat(rivetkit): export actor spans from the rust sdk
• #5781 fix(rivetkit): rebuild the workflow logger when the run's ra …
• #5782 fix(rivetkit): leave error metadata out of span error encodi … 👈
• main

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

_{change skulmuyw}

[railway-app]

This PR was not deployed automatically as @eersnington does not have access to the Railway project.

In order to get automatic PR deploys, please add @eersnington to your workspace on Railway.

[the-company-company]

✅ No issues found

_{Reviewed commit 2becb24.}

[claude]

Review: fix(rivetkit): leave error metadata out of span error encoding

Summary

Correct, well-scoped fix. Root cause is exactly what the PR description says: encodeErrorForBridge -> encodeBridgeRivetError used to JSON.stringify the full error payload (including metadata), and in actor-handle.ts:315 that call sits inside a catch block ahead of throw error;. When JSON.stringify threw on the bigint in metadata, it did so before throw error ran, so the TypeError silently replaced the real error and the caller/step saw the wrong failure (and workflow retries never got a chance to run).

I traced both call sites (actor-handle.ts:315 for outbound client() calls, napi-runtime.ts:655 for workflow step spans) down into the Rust core (OutboundCallInvocation::finish / WorkflowStepSpan::finish -> record_outcome in rivetkit-rust/packages/rivetkit-core/src/telemetry.rs:1056). record_outcome only ever reads error.group() / error.code() via RivetError::extract. So restricting the bridge-for-telemetry payload to group/code/message is not a functional regression -- metadata, rayId, statusCode, and actor were already unused on this path. Good catch narrowing the encoding to only what is consumed, which also fits this repos convention against payload debug dumps in telemetry.

Also worth noting: the real error thrown to the caller (throw error in actor-handle.ts:316) is unaffected by this change either way -- it is always the original JS error object, not the bridge-encoded string. This fix is purely about not letting telemetry encoding replace that error via an uncaught exception.

Test coverage gap

The new/renamed test (actor-telemetry.test.ts:1177) only exercises the workflow step path (napi-runtime.ts -> startWorkflowSpan().startStep().finish()). The PR description explicitly calls out a second symptom -- "A call through c.client() returned the same TypeError to its caller" -- which goes through the separate actor-handle.ts:315 call.finish(encodeErrorForBridge(error)) path. That path does not appear to have a regression test anywhere (searched for amountCents/1999n/card declined across tests/ and fixtures/).

Since rivet-error.test.ts already has a fast, isolated unit-test suite for the bridge encode/decode helpers (encodeBridgeRivetError/decodeBridgeRivetError), it would be cheap to add a direct unit test there for encodeErrorForBridge itself: assert it does not throw and drops metadata for a RivetError constructed with non-JSON-safe metadata (e.g. a bigint). That would cover both call sites without needing the slower driver-test infrastructure, and directly pins down the "encoding cannot throw" invariant the new doc comment claims.

Minor

• The updated JSDoc on encodeErrorForBridge and the fixture comment both read well and follow the repos comment conventions (complete sentences, no dashes/parentheticals).
• No security, performance, or style concerns -- this is a small, targeted fix with hard tabs preserved and no new dependencies.

Verdict

Looks correct and safe to merge. The one actionable suggestion is adding a direct unit test (or a driver test through the client() call-span path) so the second symptom described in the PR body has explicit regression coverage.

🤖 Generated with Claude Code

[the-company-company]

🟠 1 medium · 🔵 1 low

_{Reviewed commit 33c84b3.}