Stratum server accepts only string ids

[NaN-git]

The stratum server does not seem to accept requests that contain non-string ids like in
{"id":2,"method":"getjobtemplate","jsonrpc":"2.0","params":null}
Using {"id":"2","method":"getjobtemplate","jsonrpc":"2.0","params":null} works though.

[quentinlesceller]

While strange to use string for int here, this is not an issue. It's also documented in the doc https://github.com/mimblewimble/grin/blob/master/doc/stratum.md. Not sure it's really important to change that.

[NaN-git]

While strange to use string for int here, this is not an issue. It's also documented in the doc https://github.com/mimblewimble/grin/blob/master/doc/stratum.md. Not sure it's really important to change that.

Well, this behaviour isn't documented at all. The JSON RPC spec says

id
An identifier established by the Client that MUST contain a String, Number, or NULL value if included. If it is not included it is assumed to be a notification. The value SHOULD normally not be Null [1] and Numbers SHOULD NOT contain fractional parts [2]

The Server MUST reply with the same value in the Response object if included. This member is used to correlate the context between the two objects.

This means that the server is not JSON RPC 2.0 compliant.

What is the problem with this behaviour? Most software uses integers to track for examples shares because it's the easiest solution. Therefore this software is not compatible with the current server. On server side it should not matter, which data type was used in the client request.

[NaN-git]

Are there any plans or ideas how to make the stratum server JSON RPC 2.0 compliant? I don't think that this is possible without breaking compatibility with some clients.
Otherwise I would suggest that the server should also accept an integer as request id.
If the behaviour won't be fixed, then at least the documentation should be fixed. An example is not proper documentation.

[yeastplume]

I don't think it's a big ask to allow the server to accept an integer as well as a string for that field. Labelled issue accordingly if anyone wants to pick this up