-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(apps/whale-api): Add consortium transaction history endpoint #1868
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- What happens if it searches by TxId that is not part of the consortium or not a mint/burn transaction?
- Are there transactions other than mint or burn in the test container? If not, then can we add some noise to the data to check if it searches correctly?
We already have some fund transfering txes in the setup which creates |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…accounthistory` RPC (#1923) <!-- Thanks for sending a pull request! --> #### What this PR does / why we need it: **Requirement:** Upcoming consortium transaction history page on [defiscan.live](https://defiscan.live/) requires a way to paginate the list of transactions among consortium members. **Issue:** Currently we only have `blockHeight` and `depth` based pagination/cursor which we're unable to use to address the requirement as it only cursor through blocks but not transactions., More info [here](#1868 (comment)). **Solution:** - Add index based pagination support. - Add multi transaction types filter support. - Add multi address filter support. Huge thanks to @shohamc1 for supporting me on defich/ain side, refer [defich/ain PR](DeFiCh/ain#1643) Signed-off-by: Dilshan Madushanka <[email protected]> Co-authored-by: Isaac Yong <[email protected]> Co-authored-by: Kven Ho <[email protected]>
2388960
Signed-off-by: Dilshan Madushanka <[email protected]>
19ee8f0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The use of this.rpcClient.account
need to be properly designed/managed as they're expensive to call.
I spot 3 uses of this.rpcClient.account.*
; to review it properly, we need quite a lot of time to understand the implications of it. I will check with @thedoublejay on the use cases; there might be an alternative.
limit | ||
}) | ||
|
||
const totalTxCount = await this.rpcClient.account.historyCount(memberAddresses, { txtypes: [DfTxType.BURN_TOKEN, DfTxType.MINT_TOKEN] }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this is a LevelDB:Scan
all records operation, and very expensive to call. Can we avoid this or find alternatives?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For each API call, there will be maximum 2 rpc calls eventhough we have 3 this.rpcClient.account.*
usages, as the getSingleHistoryTransactionResponse
terminates the flow.
About alternatives: I couldn't find find an alternative to get total count and transactions in terms of RPCs thus I used the combination of these historyCount
and listAccountHistory
. Though, Maybe I should take a look if I can do something with the indexer?!
9e171c7
What this PR does / why we need it:
Adds transaction history endpoint to be used in upcoming consortium tab on defiscan.live
Initially, this will return transactions among consortium members related to token mints and burns.
Additional comments?:
Merge #1923 before merging this PR.