fix amendments backtracking #298
Conversation
| @@ -39,7 +39,7 @@ const AMENDMENT_VERSION_REGEX = | |||
| /\| \[(?<amendmentName>[a-zA-Z0-9_]+)\][^\n]+\| (?<version>v[0-9]*\.[0-9]*\.[0-9]*|TBD) *\|/u | |||
|
|
|||
| export const NETWORKS_HOSTS = new Map([ | |||
| ['main', 'ws://s2.ripple.com:51233'], | |||
| ['main', 'wss://xrplcluster.com'], | |||
There was a problem hiding this comment.
We often got rate limit while looping and sending ledger and tx RPC to clio (not sure if it's because of the recent issue) to backtrack amendments. We can either change this to xrpl-cluster completely or use it as a backup.
There was a problem hiding this comment.
Has this been discussed with the Clio folks?
There was a problem hiding this comment.
RippledError(You are placing too much load on the server., {\"error\":\"slowDown\",\"error_code\":10,\"error_message\":\"You are placing too much load on the server.\",\"status\":\"error This happens once in a while with Clio
There was a problem hiding this comment.
Just posted my question on their channel
There was a problem hiding this comment.
The backtrack interval is scheduled for every 30 minutes. However, new amendments are added rarely.
Can we execute the backtrackAmendmentStatus in a callback manner, only if new amendments are observed in a ledger? That should reduce the load on the Clio servers.
The non-admin feature command can be used to detect the enablement of new amendments.
There was a problem hiding this comment.
I'm surprised that the testnet and devnet haven't thrown similar "slowdown" errors, given that the amendments' status are expected to be similar between the main, dev and test networks.
There was a problem hiding this comment.
We are doing this because we are only using the entry node (so one node only) per each network to retrieve live amendments on Flag + 1 ledger. The backtracking would be just in case the entry node is down, we will use Clio. We only fetch Flag +1 ledgers in the last 30 minutes so I dont think it send too many requests to Clio
| @@ -264,11 +264,15 @@ async function backtrackNetworkAmendmentStatus( | |||
| index < currentLedger; | |||
| index += 256 | |||
| ) { | |||
| // Use api V1 instead of the default (V2) since we don't have the correct | |||
| // LedgerResponseExpanded type for V2 | |||
| // TODO: change to V2 once the issue is fixed. | |||
There was a problem hiding this comment.
I recommend linking to the xrpl.js issue
There was a problem hiding this comment.
Hello, do you remember the details of the issue pertaining to API v2 ? We are able to use the API v2 in the Ledger request for the latest validated ledger (a few lines above). I'm trying to understand why that would be a problem for other ledger indices.
The response format of the Ledger command appears to be compatible with the VHS code here
There was a problem hiding this comment.
Yes we dont need v1 now
High Level Overview of Change
There are 2 issues with amendment backtracking and status retrieval:
ledgerrpc for API v2 withtransactionsandexpandenabled does not matchLedgerResponseExpandedfield on xrpl.js. Use v1 for now.Type of Change