Make RSPCError more descriptive

[radoslavkarlik]

It just says that something failed but extra information like what procedure failed could be useful for debugging.

[oscartbeaumont]

I made the original decision to not expose the error messages because in production you don't want your backend errors leaking to a potentially malicious client but it definitely can be annoying.

Currently, you can enable the tracing feature and configure the tracing crate so you can see the errors on the server side. We do this in Spacedrive.

I will consider whether it makes sense to expose the errors to the frontend during development (when debug_assertions are enabled), I just worry that it could lead to people coding their frontends to decode or show the error message expecting it to contain the full message and then having issues when they deploy to production and the error message goes away.

[lostfictions]

As another data point: I'm using rspc with Tauri, and in that scenario I can't think of any reason I wouldn't want to surface full error messages, even in production (just the opposite: I think for debugging and user error reporting it would be extremely valuable to surface production errors to the Webkit console).

For web servers, the debug_assertions approach makes sense to me. I think showing detailed errors in dev but redacting them in production is the default behaviour for some popular server frameworks (iirc Express for Node works like this, for example).

[oscartbeaumont]

I am currently thinking I will expose control of this as a runtime configuration option because it should really be up to the application developer to decide.

For a personal note, I also need to expose JS-compatible errors within the httpz integration for a better debugging experience because a logical error message in the browser console is so much better than a HTTP status code.