Skip to content

Conversation

@lutter
Copy link
Collaborator

@lutter lutter commented Jan 29, 2026

This has two advantages:

  1. we have much more control over json-rpc processing, including better logging which jsonrpsee just doesn't provide, not even in the latest version (it's impossible to get at the remote_addr)
  2. we reduce the number of crates we depend on

Since our json-rpc server is very simple, there isn't a big downside to not relying on an external library for this

With this change, we log the following for each json-rpc request:

JSON-RPC call, x_forwarded_proto: unset, x_real_ip: unset, x_forwarded_for: unset, 
   remote_addr: 127.0.0.1:34382,
   params: Some(Object {"ipfs_hash": String("QmYourDeploymentHash"), "node_id": String("your_node_id")}),
   method: subgraph_reassign, component: JsonRpcServer

Migrate the JSON-RPC admin server from jsonrpsee to axum/tower, which
are already used elsewhere in the codebase (server/graphman). This
removes the jsonrpsee dependency while maintaining full protocol
compatibility.

Changes:
- Add jsonrpc.rs: JSON-RPC 2.0 types (request, response, error, ID)
- Add error.rs: Error code mapping from SubgraphRegistrarError
- Add handlers.rs: Request dispatch and method handlers
- Add server.rs: Axum-based HTTP server with graceful shutdown
- Update lib.rs: Module structure with public exports
- Update Cargo.toml: Replace jsonrpsee with axum, serde_json, thiserror
@lutter lutter requested a review from isum January 29, 2026 21:50
Consolidate the repetitive success/error handling pattern into a single
`to_response` helper function. Inline the error module into handlers.rs
and remove redundant per-handler logging (the dispatch function already
logs method, params, and connection info).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants