3.x.x removal of fields in /api/node/status endpoint

SDK
1

The /api/node/status endpoint returns significantly less info in 3.x.x than in 2.x.x

2.x.x result:

{
  "meta": {},
  "data": {
    "broadhash": "b4bc4a0ecbd8c473efed33481d338291a9c228dde65cec75225eb94b9a97e973",
    "consensus": 95,
    "currentTime": 1584458879573,
    "secondsSinceEpoch": 120349679,
    "height": 10376545,
    "loaded": true,
    "networkHeight": 10376545,
    "syncing": false,
    "transactions": {
      "confirmed": 1269651,
      "ready": 0,
      "verified": 0,
      "pending": 24,
      "validated": 0,
      "received": 0,
      "total": 1269675
    }
  },
  "links": {}
}

3.x.x result

{
  "meta": {},
  "data": {
    "currentTime": 1584458209545,
    "secondsSinceEpoch": 120349009,
    "height": 293863,
    "chainMaxHeightFinalized": 293715,
    "syncing": false
  },
  "links": {}
}

Is there any reason for the removal of all these fields? A lot of them were extremely useful to determine the health of a node, as well as other monitoring possibilies.

2

Hello, as of 3.0, we have removed several properties which are no longer relevant or problematic.

“broadhash”: “b4bc4a0ecbd8c473efed33481d338291a9c228dde65cec75225eb94b9a97e973”,
“consensus”: 95,
“networkHeight”: 10376545,

These 3 properties were used for calculating the consensus, but with the new BFT rules, these are no longer needed, and they don’t exist it the code anymore.

“loaded”: true,

This property was always true now after changing the initialization order, so no longer needed.

“transactions”: {
“confirmed”: 1269651,
“ready”: 0,
“verified”: 0,
“pending”: 24,
“validated”: 0,
“received”: 0,
“total”: 1269675
}

This transaction count was removed because to get the total count, query was too slow.
Also, it is not so useful property for the blockchain client to have them.
However, in the coming release, we are adding the number of unconfirmed transaction, which is necessary for the client.

1 Like
3

Thank you for the answer @shuse2.

With the new BFT rules, how would you recommend to check the ‘health’ of a node?

4

I believe before going to the mainnet, we will introduce a way to check the status easily.
The answer depends on how we define the health of the node, but in general term, if you have

  • connected peers (which you can see from the /api/peers
  • height is moving
    It should be properly moving forward with the chain.
    For the network health, chainMaxHeightFinalized should be also moving every few blocks.