👋 i noticed that errors thrown from

i noticed that errors thrown from functions called across a workers RPC boundary don't contain the original stack trace (for example when calling a function on a durable object stub or a service binding)

the serialized error that crosses the RPC boundary only contains the error message but not the stack

i'd really like to retain the original stack trace. what's a good pattern for doing that? stuff the stack trace in the message? or could i throw a custom error with the stack trace serialized in a property? would that cross the RPC boundary?

and is there a place where i can intercept any errors thrown out of the RPC boundary from the callee's side?

jonastOP•10/18/25, 7:47 PM

the docs do say that this is the case, so i'm mostly wondering what the "least inelegant" workaround would be

Larry•10/18/25, 11:06 PM

I'm pretty sure there is no way to do it from the caller side. You'd have to try/catch just inside of the method that it called. In the catch, you'd have to serialize the stack trace some how. Using the

Error

Error

class's message property is the easiest but ugly. The other option is to return some custom object. Some libraries like Supabase always return { data, error }{ data, error }. One is always null or undefined.

error

error

is NOT an instance of

Error

Error

. It's just an object with anything you want to put in it.

Larry•10/18/25, 11:26 PM

BTW, I'm not ready to recommend it for general purpose use, but my @lumenize/rpc@lumenize/rpc package's RPC implementation does transport errors across the wire. They are automatically

catch

catch

ed on the callee side, serialized in a particular way and re-

throw

throw

n on the caller side. https://lumenize.com/docs/rpc/introduction. Here is the implementation: https://github.com/lumenize/lumenize/blob/main/packages/rpc/src/error-serialization.ts. And here are integration tests confirming that stack traces survive: https://github.com/lumenize/lumenize/blob/main/packages/rpc/test/error-integration.test.ts

I am recommending @lumenize/testing@lumenize/testing which uses @lumenize/rpc@lumenize/rpc but until I understand the differences in performance and comparative limitations of each implementation, I'm going to hold off on recommending this just yet.

That said, feel free to riff off the implementation source. It's MIT licensed.

GitHub

lumenize/packages/rpc/test/error-integration.test.ts at main · lum...

Lumenize MCP-first backend as a service. Contribute to lumenize/lumenize development by creating an account on GitHub.

jonastOP•10/19/25, 3:26 PM

thank you! i was hoping there was some kind of global onError hook i could use on the caller side, but I suppose not

it just seems wild that this information is totally lost

Larry•10/19/25, 5:29 PM

I think it might be motivated by security?

vipvpn22•10/20/25, 12:18 AM

@jonast @jonast

vipvpn22•10/20/25, 11:46 PM

:blobhaj_scooter:

👋 i noticed that errors thrown from

Similar Threads

Similar Threads

Similar Threads