Typed error codes and structured error data #4

New issue

Open

opened 2026-03-02 18:33:47 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-03-02 18:33:47 +00:00

Owner

Context

The JSON-RPC layer currently uses bare integer literals for error codes, making it hard for consumers to distinguish error types without magic numbers. The data field in error responses is also untyped (Option<String>), preventing structured metadata from being attached.

Goals

Add error_codes module with named constants for all standard JSON-RPC 2.0 codes plus the APPLICATION_ERROR (-32000) application code
Change JsonRpcError.data from Option<String> to Option<Value> to carry structured error metadata
Add is_application_error() and is_method_not_found() helpers for ergonomic server-side dispatch
Expose matching error_codes constants in the client crate so consumers can distinguish errors without magic-number comparisons
Add data: Option<Value> to the internal client-side RpcError deserialization struct to prevent data loss

## Context The JSON-RPC layer currently uses bare integer literals for error codes, making it hard for consumers to distinguish error types without magic numbers. The `data` field in error responses is also untyped (`Option<String>`), preventing structured metadata from being attached. ## Goals - Add `error_codes` module with named constants for all standard JSON-RPC 2.0 codes plus the `APPLICATION_ERROR` (-32000) application code - Change `JsonRpcError.data` from `Option<String>` to `Option<Value>` to carry structured error metadata - Add `is_application_error()` and `is_method_not_found()` helpers for ergonomic server-side dispatch - Expose matching `error_codes` constants in the client crate so consumers can distinguish errors without magic-number comparisons - Add `data: Option<Value>` to the internal client-side `RpcError` deserialization struct to prevent data loss