gRPC API stringifies response values

Clients
1

Hi,

I was just testing some of the gRPC API methods and noticed that some responses have a stringified version of their value, which I doubt was the intention?

Take a look at the response from the GetConcensusStatus method. In the outer section of the response it is JSON, but the content of the value attribute is stringified JSON, which doesn’t make much sense I think?

{
  "value": "{\"bestBlock\":\"5231e15ff50c4c9d2f67a7d816a113934ad37dfb19eab9d99613d8da29269ab5\",\"genesisBlock\":\"b6078154d6717e909ce0da4a45a25151b592824f31624b755900a74429e3073d\",\"genesisTime\":\"2021-05-07T12:00:00Z\",\"slotDuration\":250,\"epochDuration\":3600000,\"lastFinalizedBlock\":\"a0f03314797a6ac4c88423e6fcec5b2a0b7ab22211f8905254b128098f48fee5\",\"bestBlockHeight\":1394250,\"lastFinalizedBlockHeight\":1394249,\"blocksReceivedCount\":6344,\"blockLastReceivedTime\":\"2021-10-21T07:57:25.414447807Z\",\"blockReceiveLatencyEMA\":-8.07385856582411e-3,\"blockReceiveLatencyEMSD\":0.13291015860393535,\"blockReceivePeriodEMA\":8.52430622862369,\"blockReceivePeriodEMSD\":6.46680156340156,\"blocksVerifiedCount\":6344,\"blockLastArrivedTime\":\"2021-10-21T07:57:25.420810317Z\",\"blockArriveLatencyEMA\":9.85953905420015e-3,\"blockArriveLatencyEMSD\":0.13397282284621745,\"blockArrivePeriodEMA\":8.52302057444369,\"blockArrivePeriodEMSD\":6.4697950237473005,\"transactionsPerBlockEMA\":1.1712478387448334e-3,\"transactionsPerBlockEMSD\":3.420345037046804e-2,\"finalizationCount\":5503,\"lastFinalizedTime\":\"2021-10-21T07:57:26.201091719Z\",\"finalizationPeriodEMA\":10.112688081016977,\"finalizationPeriodEMSD\":7.039936784331581,\"protocolVersion\":2,\"genesisIndex\":1,\"currentEraGenesisBlock\":\"532c57beea5184eb2b67a55b4ceb51308a039d76b4d238ae0a21c6db2e59a235\",\"currentEraGenesisTime\":\"2021-09-22T10:00:00Z\"}"
}

Opposed to methods like NodeInfo which has a pure JSON response, as I would expect.

{
  "node_id": {
    "value": "04d2361fe01663c0"
  },
  "current_localtime": "1634803039",
  "peer_type": "Node",
  "consensus_baker_running": false,
  "consensus_running": true,
  "consensus_type": "Passive",
  "consensus_baker_committee": "NOT_IN_COMMITTEE",
  "consensus_finalizer_committee": false,
  "consensus_baker_id": null,
  "staging_net_username": null
}
2

Yes, this is how it is specified in the proto files.

The NodeInfo’s return value is a proper NodeInfoResponse.
Meanwhile GetConsensusStatus has a JSONResponse, which just has the value field, which contains the response as a JSON blob.
Which is not great, but that is how it currently is.

3

But am I correct to assume that this would get fixed at some point and that it is not something that was made this way for any good reason?

4

We are planning to revise the node RPC interface, but I can’t say for certain when that will be done. This mishmash of ProtoBuf and JSON in particular is something I would like to address. However, the current API is likely to still be retained for a while to support our existing applications.

1 Like