According to JSON-RPC 1.0 specification the params property should be an array of object. The canonical example of calling remote methods with JSON-RPC 1.0 is to send the parameters as one dimensional JSON array:
{"method": "concat", "params": ["foo", "bar"], "id": 123}
The GO's client implementation will always wrap the params property in an additional array:
{"method": "concat", "params": [["foo", "bar"]], "id": 123}
This works fine as long as both ends use the GO's implementation and expect the actual params to be the first element of the params array. It becomes a problem if you have another server implementation of JSON-RPC 1.0 but want to use GO's client to call remote methods.
I have worked around this issue locally by fixing it in my go fork.
Comment From: katiehockman
/cc @robpike
Comment From: robpike
I don't see how to fix this without breaking things. I don't see how to leave this alone without breaking things. Help wanted.
Comment From: jamdagni86
@stefangluszek are u sending a PR for this?
Comment From: stefangluszek
No because the fix is not backward compatible. It's still the right fix but it will break the existing clients and servers. You would either have to upgrade both client and the server with the fix or make changes to your client to explicitly wrap the param in an array before passing it to jsonrpc.Call. I am not sure what is the GO policy on backward compatibility.
Comment From: robpike
The policy is we can't break things except under very special circumstances that I'm not convinced apply here.
https://golang.org/doc/go1compat
Comment From: alexus1024
The usual way of fixing problems like that - is a switch "fixed_jsonrpc1_array_parameters_behaviour" :) in client struct. Defaulted to false value. With a plan to change default value to true in future. Not a great solution, but solution. And it will not break backward compatibility.
Comment From: stefangluszek
Yes adding a feature flag to protect the change would work, not pretty though.
Comment From: mohanson
I've been following this issue for a while now. Actually, this issue with net/rpc/jsonrpc makes it almost impossible for jsonrpc servers or clients written in Go to work well with other languages(That's why I've always avoided using this package). This is a compatibility issue, and it's been difficult to fix it in the past. But now, perhaps we can introduce net/rpc/jsonrpc/v2 to solve this problem, just like math/rand/v2 and encoding/json/v2 did, and then at some point in the future, fix this problem completely.