Core dispatch pipeline: lookup → middleware → validate input → invoke handler → validate output → serialize.

Every transport (HTTP Plug, in-process caller) funnels through dispatch/4, which threads a %RpcElixir.Resolution{} through the procedure's middleware chain and the inner pipeline. The returned resolution carries the final outcome on its :result field, so middleware that wraps dispatch/4 can observe and transform results uniformly.

Typed handler errors

When a handler returns {:error, reason}, the dispatcher promotes reason to a top-level %RpcError{}:

• reason is an atom: code = reason, message = Atom.to_string(reason), details = nil. HTTP status is derived by the transport from RpcElixir.RpcError's framework status map (falling back to a generic status).
• reason is a plain map (not a struct) with :code (atom): code = reason.code, message = reason[:message] || Atom.to_string(code), details = reason minus :code and :message (or nil if empty). HTTP status is derived by the transport from RpcElixir.RpcError's framework status map (falling back to a generic status).
• reason is already an %RpcError{} with a non-nil :source: passed through unchanged. If :source is nil, it is stamped with source: :domain before being returned.
• Anything else (structs, tuples, keyword lists, lists, …): wrapped as %RpcError{code: :handler_error, details: %{kind: :error, reason: inspect(reason)}} with status 500 (the default status for :handler_error in RpcElixir.RpcError.framework_errors/0). These are framework-level "handler returned something unexpected" cases.

This contract matches the JS Error shape on the TypeScript client: err.code, err.message, and err.details are all populated for typed errors, and err.message shows up in stack traces and console.error.