feat/gorilla rpc

[igor-sirotin]

Pros:

• Recover from panic (report them to sentry and re-panic)
• 1 less dependency on go-ethereum (though we'll still use its rpc.Client)

Cons:

• Requires changing signature of all RPC methods
• Changes service_method signature to service.method
• Relies a lot on HTTP.
  • Enforces HTTP wrapping.
    Simple http.Request doesn't seem to harm though. And can be useful for status-bacend
  • When a non-method error occurs, (e.g. fail to unmarshal arguments), returns HTTP code 400 and non-json body:

  b'json: cannot unmarshal object into Go value of type [1]interface {}'
  

  To compare, go-ethereum RPC server returns this:

  {
    "error": {
      "code": -32602,
      "message": "non-array args"
    },
    "id": 3,
    "jsonrpc": "2.0"
  }

  Both approaches make sense to me. But we would need to adapt our code for HTTP codes.

[github-actions]

Thank you for opening this pull request!

We require pull request titles and commits to follow the Conventional Commits specification and it looks like your PR needs to be adjusted.

Details:

No release type found in pull request title "feat/gorilla rpc". Add a prefix to indicate what kind of release this pull request corresponds to. For reference, see https://www.conventionalcommits.org/

Available types:

• feat: A new feature
• fix: A bug fix
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• refactor: A code change that neither fixes a bug nor adds a feature
• perf: A code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
• ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit

[status-im-auto]

Jenkins Builds

Click to see older builds (18)

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
✔️	d15db5c	#1	2025-09-23 10:17:02	~3 min	linux/status-go	📦zip
✖️	d15db5c	#1	2025-09-23 10:17:32	~4 min	tests	📄log
✔️	d15db5c	#1	2025-09-23 10:17:38	~4 min	macos/status-go	📦zip
✔️	d15db5c	#1	2025-09-23 10:18:56	~5 min	windows/status-go	📦zip
✔️	d15db5c	#1	2025-09-23 10:23:05	~9 min	tests-rpc	📄log
✔️	d15db5c	#1	2025-09-23 10:24:23	~11 min	linux/nwaku	📦zip
✔️	3f81340	#2	2025-09-23 10:22:23	~3 min	linux/status-go	📦zip
✖️	3f81340	#2	2025-09-23 10:23:17	~3 min	tests	📄log
✔️	3f81340	#2	2025-09-23 10:24:42	~5 min	windows/status-go	📦zip
✔️	3f81340	#2	2025-09-23 10:25:31	~6 min	macos/status-go	📦zip
✔️	3f81340	#2	2025-09-23 10:32:52	~9 min	tests-rpc	📄log
✔️	3f81340	#2	2025-09-23 10:35:26	~10 min	linux/nwaku	📦zip
✔️	36a5b63	#3	2025-09-23 10:32:58	~3 min	macos/status-go	📦zip
✔️	36a5b63	#3	2025-09-23 10:32:59	~3 min	linux/status-go	📦zip
✖️	36a5b63	#3	2025-09-23 10:33:34	~3 min	tests	📄log
✔️	36a5b63	#3	2025-09-23 10:35:09	~5 min	windows/status-go	📦zip
✖️	36a5b63	#3	2025-09-23 10:42:01	~9 min	tests-rpc	📄log
✔️	36a5b63	#3	2025-09-23 10:45:41	~10 min	linux/nwaku	📦zip

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
❌	db30ef2	#4	2025-09-24 11:13:18	~1 min	macos/status-go	📄log
❌	db30ef2	#4	2025-09-24 11:15:05	~3 min	windows/status-go	📄log
❌	db30ef2	#4	2025-09-24 11:16:55	~5 min	linux/status-go	📄log
✖️	db30ef2	#4	2025-09-24 11:20:15	~8 min	tests	📄log
✖️	db30ef2	#4	2025-09-24 11:23:35	~11 min	tests-rpc	📄log
❌	db30ef2	#4	2025-09-24 11:24:18	~12 min	linux/nwaku	📄log
✔️	6f366c6	#5	2025-09-24 11:57:16	~3 min	linux/status-go	📦zip
✖️	6f366c6	#5	2025-09-24 11:57:24	~3 min	tests	📄log
✔️	6f366c6	#5	2025-09-24 11:57:49	~4 min	macos/status-go	📦zip
✔️	6f366c6	#5	2025-09-24 11:59:12	~5 min	windows/status-go	📦zip
✔️	6f366c6	#5	2025-09-24 12:03:57	~10 min	linux/nwaku	📦zip
✖️	6f366c6	#5	2025-09-24 12:08:14	~14 min	tests-rpc	📄log

[igor-sirotin]

I've looked into gorilla/rpc/v2, which is JSON-RPC 2.0. An unmarshal error response looks like this now:

{
  "result": null,
  "error": "json: cannot unmarshal object into Go value of type [1]interface {}",
  "id": 1
}

Which looks better - now it's a JSON. But actually doesn't follow the JSON-RPC 2.0 specification:
https://www.jsonrpc.org/specification

The go-ethereum JSON-RPC implementation, on the other hand, seem to be following the specification correctly.

You know, we love specifications... 🤔