refactor(katana): remove starknet crate dependency from RPC client

[kariy]

Summary

Removed dependency on the starknet crate from the Katana RPC debugging client and replaced it with Katana's native types, using jsonrpsee for proper JSON-RPC handling.

This new implementation will also help us better validate our own RPC types.

Original Instructions

The user requested the following changes to the Katana RPC client:

1. Remove all reliance on the starknet crate - The RPC client implementation in bin/katana/src/cli/rpc/client.rs was based solely on types from the starknet crate
2. Use Katana's own RPC types - Replace starknet types with types from crates/rpc/rpc-types/src
3. Replace HttpTransport with direct HTTP client usage - Avoid using HttpTransport from starknet crate
4. Return raw JSON responses - The client should display the raw JSON response objects (not deserialize into proper types) as this CLI command is meant to be used primarily as a debugging tool to validate RPC server responses
5. Use Katana's error types - Use the Starknet API error types from crates/rpc/rpc-api/src/error/starknet.rs

Evolution of Implementation

Initial Implementation (First Commit)

Initially implemented a manual JSON-RPC client using reqwest:

• Created manual JSON-RPC request/response structs
• Used reqwest::Client directly for HTTP requests
• Manually handled JSON-RPC error conversion to StarknetApiError
• ~270 lines of code with significant boilerplate

Improved Implementation (Second Commit)

After discussion, refactored to use jsonrpsee for cleaner JSON-RPC handling:

• Uses jsonrpsee::http_client::HttpClient - Proper JSON-RPC client with built-in protocol handling
• Leverages ClientT::request method - Returns raw serde_json::Value for debugging
• Uses ArrayParams - Type-safe parameter handling from jsonrpsee
• Removed manual JSON-RPC code - No more custom request/response structs
• Better error handling - jsonrpsee handles JSON-RPC errors automatically
• ~30% less code - Cleaner, more maintainable implementation

Final Refinement (Latest Commit)

Aligned the client method signatures with the existing starknet client:

• Removed to_json() methods - BlockIdOrTag/ConfirmedBlockIdOrTag already implement Serialize/Deserialize
• Updated method signatures to match crates/rpc/rpc-client/src/starknet.rs exactly:
  • Use proper typed arguments (ContractAddress, StorageKey, ClassHash, etc.)
  • Maintain raw Value return types for debugging purposes
• Improved type safety - Use FunctionCall struct directly instead of manual JSON construction
• Automatic serialization - Let Serialize trait handle JSON conversion

Thought Process & Alternatives Considered

Initial Approach

Initially planned to simply replace the starknet crate types with Katana types while maintaining the same client structure.

Alternative Considered: Reusing katana-rpc-client

During implementation, we considered reusing the existing katana-rpc-client (at crates/rpc/rpc-client/src/starknet.rs) instead of maintaining two separate client implementations. This client:

• Already uses all Katana's native types
• Uses jsonrpsee with the trait-based API from katana-rpc-api
• Has proper error handling with StarknetApiError
• Would eliminate code duplication

Why We Kept a Separate Implementation

After discussion, we decided to maintain a separate client implementation for the CLI debugging tool because:

1. Different Purpose: The CLI client is specifically for debugging and validating raw RPC responses, while katana-rpc-client is for programmatic use
2. Raw JSON Output Required: The user explicitly wanted to see raw JSON responses to validate server output, not deserialized typed responses
3. Debugging Focus: A simpler, direct implementation gives better control and visibility for debugging purposes
4. Independence: Having a separate implementation allows the debugging client to evolve independently without affecting the main RPC client

Final Improvement: Using jsonrpsee

Realized that using jsonrpsee (already in the project dependencies) would provide:

• Proper JSON-RPC 2.0 compliance
• Built-in error handling
• Less code to maintain
• Better compatibility with the rest of the codebase

Final Implementation

• Dependencies: Removed starknet and reqwest, added jsonrpsee with http-client feature to bin/katana/Cargo.toml
• RPC Client: Uses jsonrpsee with proper typed method signatures matching the starknet client
• Type Replacements:
  • starknet::core::types::BlockId → katana_primitives::block::BlockIdOrTag
  • starknet::core::types::ConfirmedBlockId → katana_primitives::block::ConfirmedBlockIdOrTag
  • starknet::core::types::BlockTag → Direct enum variants
  • starknet::core::types::FunctionCall → katana_rpc_types::FunctionCall
  • starknet::providers::jsonrpc::HttpTransport → jsonrpsee::http_client::HttpClient
  • ContractAddress, StorageKey, ClassHash, Nonce → All from katana_primitives
• Updated starknet.rs:
  • Removed to_json() methods since types already implement Serialize
  • Uses BlockIdOrTag/ConfirmedBlockIdOrTag directly
  • Uses FunctionCall struct instead of manual JSON construction
• Updated tests: Changed test assertions to use Katana types

Motivation

The RPC client in the Katana binary is primarily used as a debugging tool to validate RPC server responses. By removing the external starknet crate dependency and using Katana's own types with proper JSON-RPC handling via jsonrpsee, we:

1. Reduce external dependencies
2. Maintain consistency with the rest of the codebase
3. Have cleaner, more maintainable code
4. Get raw JSON responses for better debugging visibility
5. Ensure proper JSON-RPC 2.0 compliance
6. Achieve better type safety with proper method signatures

Test Plan

• Verify all RPC commands still work correctly against a running Katana node
• Test that raw JSON responses are properly displayed
• Ensure all commands handle errors appropriately
• Validate that the client works with different block ID formats (latest, hash, number)

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 20.91503% with 121 lines in your changes missing coverage. Please review.
✅ Project coverage is 75.26%. Comparing base (9bde0ae) to head (85ef74a).
⚠️ Report is 114 commits behind head on main.

Files with missing lines	Patch %	Lines
bin/katana/src/cli/rpc/client.rs	0.00%	72 Missing ⚠️
bin/katana/src/cli/rpc/starknet.rs	42.66%	43 Missing ⚠️
bin/katana/src/main.rs	0.00%	5 Missing ⚠️
bin/katana/src/cli/rpc/mod.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #268      +/-   ##
==========================================
+ Coverage   73.32%   75.26%   +1.93%     
==========================================
  Files         209      230      +21     
  Lines       23132    27127    +3995     
==========================================
+ Hits        16961    20416    +3455     
- Misses       6171     6711     +540     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.