Skip to content

Conversation

@ledhed2222
Copy link
Contributor

@ledhed2222 ledhed2222 commented Jul 20, 2023

Properly close connections and use timeouts for requests so that we actually quit when we're rate-limited and something like systemd or forever can handle instead of just spinning.

this took a while to figure out (it was the timeouts with xrpl-client). i had to refactor everything to use async to even really understand what was going on.

you'll definitely want to review using "split mode", since I completely rewrote the index.js and ledgerIndex.js scripts

index.js Outdated
}

Client.ready().then(Connection => {
Client.ready().then(() => {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed this since I know understand that Client.ready returns Client anyway and we have that variable in global scope here. fewer variables is easier to read.

index.js Outdated
console.log('Insert errors:')
err.errors.forEach(err => console.dir(err, { depth: null }))
process.exit(1)
return safeHalt()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI - I personally do not like .then and greatly prefer async/await. It took me forever to remember how to await a promise from within another promise, conditionally, without nesting. to me, the fact that returning a promise from then will await the returned promise is too magical. async/await is much clearer

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

have we considered using util.promisify to wrap this callback function bigquery.dataset(DATASET_NAME).table(TRANSACTION_TABLE_NAME).insert portion?

Copy link

@kennyzlei kennyzlei left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of defining safeHalt and needing to catch every possible exception and call it, have you considered using a higher level error handling in node? I think defining a process.on('uncaughtException' ... and process.on('unhandledRejection' can allow you to catch these errors on the high level and not need to do a bunch of .then code clauses on callbacks that just call safeHalt

index.js Outdated
console.log('Insert errors:')
err.errors.forEach(err => console.dir(err, { depth: null }))
process.exit(1)
return safeHalt()

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

have we considered using util.promisify to wrap this callback function bigquery.dataset(DATASET_NAME).table(TRANSACTION_TABLE_NAME).insert portion?

index.js Outdated
Comment on lines 64 to 69
const txPromises = result.ledger.transactions.map((tx) => {
return client.send({
command: 'tx',
transaction: tx,
}, xrplRequestOptions)
})

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you potentially run into a rate limit here if you're sending a ton of client requests at the same time?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you were using the promise-utils lib i linked you earlier, a mapLimit could be used to limit the number of parallel requests happening (https://blend.github.io/promise-utils/latest/index.html#maplimit)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants