Repository navigation
Conversation
JSON-RPC 1.0-style servers (Bitcoin Core and its forks, among others) always include the "error" member and set it to null on success. The response parser handed the literal "null" to ParseError, whose fallback turned it into a server-side exception, so every successful call to such a node was reported as a failure and retried against other upstreams. Treat a null error as the absence of an error, both in the streaming parser and in ParseError (used by the batch and from-bytes paths). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…tecture eRPC currently serves EVM and SVM chains, each with a chain model (chain-id or genesis detection, state poller, method hooks). Many other chains expose a plain JSON-RPC API (Bitcoin-family nodes, Stellar RPC, and others) and only need eRPC's generic pipeline: upstream selection, failsafe policies, rate limiting, multiplexing, metrics and healthchecks. Add a third architecture, "jsonrpc", that provides exactly that and nothing chain-specific: - architecture/jsonrpc registers a no-op ArchitectureHandler through the architecture registry; its error extractor claims nothing, so errors fall through to the default extractor (HTTP status + standard JSON-RPC codes). - Networks: `architecture: jsonrpc` with `jsonRpc.id` (defaults to the alias); network id "jsonrpc:<id>". Inferred from a `jsonRpc` block, never receives networkDefaults.evm, and can be created lazily from the URL (/<project>/jsonrpc/<id>) like other architectures. - Upstreams: `type: jsonrpc` with `jsonRpc.networkId` (type is inferred when networkId is set). Bootstrap only derives the network id from config; nothing is sent to the node. They reuse the generic HTTP and WebSocket JSON-RPC clients; gRPC endpoints are rejected. - Requests are validated as JSON-RPC and forwarded unchanged (no normalization); finality is unknown unless set via methods.definitions, and no cache is wired since there is no block/slot model. - Healthcheck scoping and all:activeUpstreams counting understand jsonrpc networks. - TypeScript config types regenerated with tygo; NetworkArchitecture and UpstreamType unions extended. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
"params" is optional in JSON-RPC 2.0, and some non-EVM JSON-RPC servers
reject an empty positional array ("params":[]) for methods without
parameters while accepting the member being absent.
The new upstream setting jsonRpc.omitEmptyParams leaves the member out of
outbound requests whose params are empty, for the HTTP client (single and
batch) and the WebSocket client. It defaults to true for upstreams of type
jsonrpc and false otherwise, so the wire format of evm and svm upstreams
is unchanged unless the setting is turned on.
The request cache hash is computed from the parsed params, not from the
wire bytes, so cache keys are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Describe the architecture, the networks[].jsonRpc and upstreams[].jsonRpc.networkId fields, type inference and the behavioral differences from evm/svm (no detection, no cache, unknown finality), with YAML/TypeScript examples. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
eRPC serves EVM and SVM chains, each with a chain model (chain-id or genesis detection, state poller, method hooks). Many other chains expose a plain JSON-RPC API (Bitcoin-family nodes, Stellar RPC and others) and only need eRPC's generic pipeline: upstream selection, failsafe policies, rate limiting, multiplexing, metrics and healthchecks.
This adds a third architecture,
jsonrpc, that provides exactly that and nothing chain-specific, plus two wire-level changes such servers need.Commits (reviewable separately):
fix(json-rpc): treat"error": nullin upstream responses as success. JSON-RPC 1.0-style servers (Bitcoin Core and forks) always send"error": null; today every successful call to such a node is parsed as a server error and retried elsewhere.feat(architecture): thejsonrpcarchitecture.architecture/jsonrpcregisters a no-opArchitectureHandler; errors fall through to the default extractor.architecture: jsonrpcwithjsonRpc.id(defaults to the alias); network idjsonrpc:<id>; inferred from ajsonRpcblock; lazily creatable from/<project>/jsonrpc/<id>.type: jsonrpcwithjsonRpc.networkId(type inferred when set). Bootstrap sends nothing to the node. HTTP and WebSocket clients are reused; gRPC endpoints are rejected.methods.definitions; no cache (no block/slot model).all:activeUpstreamsunderstandjsonrpcnetworks. TypeScript config types regenerated with tygo.feat(json-rpc):upstreams[].jsonRpc.omitEmptyParams. Leavesparamsout of outbound requests whose params are empty instead of sending"params":[];paramsis optional in JSON-RPC 2.0 and some servers reject an empty array for methods without parameters. Defaults totruefortype: jsonrpcupstreams andfalseotherwise, so the wire format of EVM and SVM upstreams does not change unless the setting is turned on. Cache keys are unchanged (hashed from parsed params).docs:config/projects/networksandconfig/projects/upstreams.Verification
Based on
erpc/erpcmain @ 094b912.go build ./...,go vet ./...andgofmt -lon touched files are clean.make test-fast(what CI runs): passes, exit 0, no failing test.TestJsonRpcRequest_WireRequest,TestUpstreamConfig_SetDefaults_OmitEmptyParams(false for evm, true for jsonrpc, explicit opt-out respected),TestHttpJsonRpcClient_OmitEmptyParams(default, disabled, enabled). The passthrough end-to-end test checks that ajsonrpcupstream receives noparamsfor an empty call.tygo generate.AI assistance
🤖 Generated with Claude Code