Sometimes json-rpc ledger api returns undocumented response. (Version: v1.8.4)

sokiaoba commented 2 years ago

Issue Description

Somtimes json-rpc ledger api returns undocumented response.

Steps to Reproduce

Unknown. (My speculation is, this happens when the requested ledger is already proposed but not yet validated)

Expected Result

Json-rpc ledger api should return documented response here like below, or if this is intented behavior, better to be documeneted.

{
  "result": {
    "ledger": {
      "accepted": true,
      "account_hash": "B258A8BB4743FB74CBBD6E9F67E4A56C4432EA09E5805E4CC2DA26F2DBE8F3D1",
      "close_flags": 0,
      "close_time": 638329271,
      "close_time_human": "2020-Mar-24 01:41:11.000000000 UTC",
      "close_time_resolution": 10,
      "closed": true,
      "hash": "3652D7FD0576BC452C0D2E9B747BDD733075971D1A9A1D98125055DEF428721A",
      "ledger_hash": "3652D7FD0576BC452C0D2E9B747BDD733075971D1A9A1D98125055DEF428721A",
      "ledger_index": "54300940",
      "parent_close_time": 638329270,
      "parent_hash": "AE996778246BC81F85D5AF051241DAA577C23BCA04C034A7074F93700194520D",
      "seqNum": "54300940",
      "totalCoins": "99991024049618156",
      "total_coins": "99991024049618156",
      "transaction_hash": "FC6FFCB71B2527DDD630EE5409D38913B4D4C026AA6C3B14A3E9D4ED45CFE30D"
    },
    "ledger_hash": "3652D7FD0576BC452C0D2E9B747BDD733075971D1A9A1D98125055DEF428721A",
    "ledger_index": 54300940,
    "status": "success",
    "validated": true
  }
}

Actual Result

Some keys (ex. "ledger_index") are missing and some keys ("ledger_current_index") are added.

{
  "result":{
     "ledger":{
        "closed":false,
        "ledger_index":"69897509",
        "parent_hash":"4A8FD616661EE5BFE77288BFF4F00707EDF7312AFF81E8649F42829F70CEADB8",
        "seqNum":"69897509",
        "transactions":[
           "0124A0C7000094E1AAEDA336B71D9F1C4CEF55847F205528837A08AA17F98286",
           "11FB9174DF1B4024BBF3DF8898D03CEB7856A169BC7E612EDBD0F9987029DF47",
           "169CD64481AC9FA48388982E11153E0A5DA421DAC3A888BF415929E053719A02",
           "16C5FA8B2193FDF6A7093B4E631D0BFCADD553673B310DA25A2CFF01C975DA5E",
           "307A96E7C79BE03848561D775286C43FDD3A7B5B97999D3BAEB942075B7CCF87",
           "42F6D83372142FB609BC84113D82A65336E078BF042DBA1D3C4274B8DEB8DDAE",
           "43EC95C3876CF175A8C7D0EB06CB8DD1100317442DA804E1BD53B88E0FE2ABA2",
           "49D96B39848023AAE70CD84224AD000438C64222086F66724F85D0D92A0760C3",
           "643436B9B698CBC7C0678C902480E9196DBD0CA3441BB6F8B2B5D0310D35D0B3",
           "6AA48B7B30480F21226E08A36A26C0DA0BD98F9C5787606AC8FE67A05AD7A144",
           "734021798056AA2DD4FA084D0FBF1EB20FD66AF85E597DD6FC423CB7ADB3526D",
           "7D19028B72E1EE7B174D6400EDE2E86B9999E46CEA36B4AED56DA3FA31951DC1",
           "8BFC32FA449137C3045DBEBD36601173ABCE20C7486F9D95B0C822DBDB17ABED",
           "910B0F85BA4F9C04095C186751960E2C5683E3FEED35EB2DD7746546E20D217F",
           "A01EE7EF01B8B0C47C409151E1D1CC704A9DF06D64A1F95EA39D02813B98575A",
           "A08F41DD8402F9F77CDAA8396A39D399DACBB8303A6BFC77D2E073CC11C13C13",
           "AE9326C3DE887B3493A8C17EC19A22A3E9AFFC1391904AF731EF499C6E112DCE",
           "AEE70D5A405C9776E8DAC570C632D8E2737B41618A25253F1025F62D92E8FFF7",
           "B0D748210944E42FB37330EA73C39A7A725D80034FD7E796422B5244531653B4",
           "C130F9780A82DCEFA644634171CAF5C14BCBD0022401BCD76F0A4B5A630DDD65",
           "C1D27964CE71EB9F648448E9A1FA244FA9BC9310AF5AF20FBD0FBDECE1BEECC4",
           "C42AFAC909F527BB8B70DA2E191304F4CA0C34938A23035BB74E4598C47AADAF",
           "D651900D689A5BDAF7D1EEE04850E874F3F2FFE2C90CC19FA30EE41A2FB0F467",
           "E9CCC0D2087BF675A19122AEAC2DECEDC1309DFE7E9F6B3721FF66C249C554C3",
           "F9C16930C84945C112B5A01885F91B8EE0D0B59A403B37D1BE926EB88742BBE4"
        ]
     },
     "ledger_current_index":69897509,
     "status":"success",
     "validated":false
  }
}

Environment

rippled: v1.8.4

ximinez commented 2 years ago

What is the request that is generating this response?

The first response looks like a validated ledger, the second response looks like the current ledger. If you request ledger without a ledger index, hash, or one of the special index values - current, closed, validated - you will get the default ledger. In peer-to-peer mode, the default is the current, while in reporting mode, the default is validated. (Documentation.) The results you're observing may be as a result of connecting to different servers between requests, something that is common and expected if you're using a publicly available server pool.

It does look like there's a gap in the documentation related to the current ledger. Attn: @mDuo13

BTW, I noticed you linked to the xrpl-dev-portal github repo for documentation. That is the "source" used to publish to xrpl.org, which I recommend unless you're looking for unpublished info on upcoming features.

sokiaoba commented 2 years ago

@ximinez

Thank you.

The request which generated the response should be something like this.

{
    "method": "ledger",
    "params": [
        {
            "ledger_index": 69897509,
            "transactions": true,
            "expand": false
        }
    ]
}

And the request was sent to our hosting node (which is running in p2p mode).

If you request ledger without a ledger index, hash, or one of the special index values - current, closed, validated - you will get the default ledger. In peer-to-peer mode, the default is the current, while in reporting mode, the default is validated. (Documentation.) The results you're observing may be as a result of connecting to different servers between requests, something that is common and expected if you're using a publicly available server pool.

So, this wound not be our case.

BTW, I noticed you linked to the xrpl-dev-portal github repo for documentation. That is the "source" used to publish to xrpl.org, which I recommend unless you're looking for unpublished info on upcoming features.

Thanks 👍

ximinez commented 2 years ago

It is possible to request the current ledger by the numeric index. For example, this shell script demonstrates that, even though it's contrived.

index=$( rippled -q json ledger '{ "ledger_index": "current" }' | jq '.result.ledger_current_index' )
echo Requesting index $index
# Will return the current ledger _almost_ every time
rippled -q json ledger '{ "ledger_index": '$index', "transactions": true}'

My assumption right now is that the way you're deciding which index to request has some kind of bug. For example, if it's incrementing a counter and polling, you may need to handle this case by having a short delay and trying again. If it's event-driven based on a subscription to rippled's ledger stream, there may be a race condition. My example code has a race condition the other way in that if the ledger validated between the first command and the last, it won't return the open ledger.

Thanks +1

You're welcome!

sokiaoba commented 2 years ago

@ximinez

It is possible to request the current ledger by the numeric index.

If it's event-driven based on a subscription to rippled's ledger stream, there may be a race condition.

Ah, thank you! Probably that's the case I'm facing.

I think it's nicer to have this behaviour documented as you mentioned here. https://github.com/ripple/rippled/issues/4107#issuecomment-1050004977

XRPLF / rippled