Open sokiaoba opened 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.
@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 👍
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!
@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
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.
Actual Result
Some keys (ex. "ledger_index") are missing and some keys ("ledger_current_index") are added.
Environment
rippled: v1.8.4