Summary

errorResponseFromCatch in packages/core/src/rpc.ts forwards the raw error.message and error.name from any non-ApiError throw straight into the JSON-RPC error response returned to the client. When the underlying failure comes from a driver or SDK (Postgres, DynamoDB, etc.), the internal exception class name and raw message end up on the wire. This is both an information-disclosure concern and an error-quality problem.

Where

• packages/core/src/rpc.ts — errorResponseFromCatch() sets message = error.message for any Error, and copies error.name into data.name whenever it isn't the generic Error.
• Emitted to clients by:
  • packages/core/src/lambda-handler.ts (RPC error branch)
  • packages/core/src/scripts/dev-server.ts (dev-server RPC branch)

Impact

• Non-ApiError throws (the common case for driver/SDK failures) return an HTTP 200 JSON-RPC error whose message is the raw driver message and whose data.name is the raw exception class name.
• Leaks internal implementation details to any caller and produces unstable, non-actionable error shapes for clients.

Expected

Only ApiError (or an explicitly allowed shape) should reach the client verbatim. Everything else should collapse to a stable, generic error (e.g. code 500, message: "Internal error"), with the detailed error logged server-side only.

Suggested fix

Sanitize the non-ApiError branch of errorResponseFromCatch so unknown errors map to a generic message/code and never copy error.name or the raw error.message onto the wire.