Unparseable JSON in output

[LLParse]

When I run etcdctl endpoint status -w json I get this output:

[{"Endpoint":"127.0.0.1:2379","Status":{"header":{"cluster_id":983170781618320308,"member_id":146208323496824608,"revision":1,"raft_term":2},"version":"3.1.0","dbSize":24576,"leader":18091059109996920133,"raftIndex":294,"raftTerm":2}}]

Most implementations of JSON parsers are not going to understand this JSON - the integers are too large to be represented as 64-bit float without losing precision. I'd recommend exposing the IDs as a string. I ran into this yesterday when using the jq utility.

All of JavaScript is 64-bit float so most implementations of JSON parsers are implicitly the same, since the spec explicitly does not define any behavior ("JSON is agnostic about numbers").

I am munging the simple output for now, can you provide any guarantees that the output ordering will remain consistent for all releases 3.1.X?

[gyuho]

can you provide any guarantees that the output ordering will remain consistent for all releases 3.1.X?

Most likely, I don't think we would ever reorder fields in proto

/cc @heyitsanthony @xiang90 ?

[heyitsanthony]

It depends on whatever the go json encoder does. So long as it's building with the same go version it should be stable.

The JSON fields can be made strings but protoc will need to generate a json field tag that coerces it into a string.

[xiang90]

i would rather stay at the default Porto to Json mapping standard.

[LLParse]

Sorry, to be more clear - I am munging the simple output for now:

$ etcdctl endpoint status -w simple
127.0.0.1:2379, 3065dd2f2c120c24, 3.1.0, 25 kB, true, 2, 786

Is the ordering going to remain static? Or should I ship a 6MB binary built with Go to parse the JSON.

[xiang90]

Simple is stable. We won't break it without clear communication and deprecation plan.