Inconsistent server_info response (Version: s1, s2)

anhcao142 commented 3 years ago

Issue Description

I use info.validated_ledger.base_fee_xrp and info.load_factor from server_info to calculate fee but sometime the response json is missing info.load_factor, e.g. this response

{
  "result": {
      "info": {
          "build_version": "1.7.0",
          "complete_ledgers": "32570-62713383",
          "hostid": "DUG",
          "io_latency_ms": 1,
          "last_close": {
              "converge_time_s": 0,
              "proposers": 0
          },
          "pubkey_node": "n9Krd83Ab8rW29LhNZPNQ3EFYBs59V1k7sGu1WizLNogrCEi56kF",
          "published_ledger": "none",
          "reporting": {
              "etl_sources": [
                  {
                      "connected": true,
                      "grpc_port": "50051",
                      "ip": "10.30.32.34",
                      "last_message_arrival_time": "2021-Apr-06 10:34:33.171053 UTC",
                      "validated_ledgers_range": "61506690-62713383",
                      "websocket_port": "51233"
                  },
                  {
                      "connected": true,
                      "grpc_port": "50051",
                      "ip": "10.30.32.170",
                      "last_message_arrival_time": "2021-Apr-06 10:34:33.172233 UTC",
                      "validated_ledgers_range": "61916861-62713383",
                      "websocket_port": "51233"
                  }
              ],
              "is_writer": true,
              "last_publish_time": "2021-Apr-06 10:34:31.612887 UTC"
          },
          "server_state": "full",
          "server_state_duration_us": "649088585088",
          "state_accounting": {
              "connected": {
                  "duration_us": "0",
                  "transitions": 0
              },
              "disconnected": {
                  "duration_us": "34471",
                  "transitions": 1
              },
              "full": {
                  "duration_us": "649088585088",
                  "transitions": 1
              },
              "syncing": {
                  "duration_us": "0",
                  "transitions": 0
              },
              "tracking": {
                  "duration_us": "0",
                  "transitions": 0
              }
          },
          "time": "2021-Apr-06 10:34:33.293823 UTC",
          "uptime": 649092,
          "validated_ledger": {
              "age": 3,
              "base_fee_xrp": 1e-05,
              "hash": "F04E9B08596F86DEF1F55FA29380C1ECC04079DA0A9539FE60E85ADC092C292A",
              "reserve_base_xrp": 20,
              "reserve_inc_xrp": 5,
              "seq": 62713383
          },
          "validation_quorum": 1
      },
      "status": "success",
      "warnings": [
          {
              "id": 1004,
              "message": "This is a reporting server.  The default behavior of a reporting server is to only return validated data. If you are looking for not yet validated data, include \"ledger_index : current\" in your request, which will cause this server to forward the request to a p2p node. If the forward is successful the response will include \"forwarded\" : \"true\""
          }
      ]
  }
}

Steps to Reproduce

try to request to s2 or s1 several times and you might encounter response that doesn't have load_factor

curl -L -X POST 'https://s2.ripple.com:51234/' -H 'Content-Type: application/json' --data-raw '{
    "method": "server_info",
    "params": [
        {
        }
    ]
}'

Expected Result

server_info should be consistent

Actual Result

load_factor sometime is missing

LynchEntrostat commented 3 years ago

I am experiencing this as well and it causes ripple-lib to fail to make payments when the load_factor is missing.

ximinez commented 3 years ago

As indicated by the warning message, the query is hitting a reporting server. s1 and s2 contain a mix of reporting mode and P2P ("normal") mode servers. Because reporting mode does not handle protocol traffic, it really doesn't have any need to worry about a load_factor, so you can treat it as if it returned 1.

s1 and s2 are public services intended for testing and development. They provide no service guarantees. If you want to use the XRP ledger in a production context, the best practice is to run your own server and send all your queries to it. See also https://xrpl.org/the-rippled-server.html#reasons-to-run-your-own-server

XRPLF / rippled