Skip to content
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

getTransactionsWithPageInfo won't iterate through pages when pageFilter is defined #268

Open
GusGold opened this issue Mar 25, 2024 · 0 comments

Comments

@GusGold
Copy link

GusGold commented Mar 25, 2024

getTransactionsWithPageInfo accepts both pageFilter as well as a nextOrPreviousPath argument. The current logic will only use pageFilter when it is defined, even if nextOrPreviousPath is also defined. This leads to unexpected behaviour where providing nextOrPreviousPath on subsequent calls to attempt to page through the transaction list will not page at all, and instead keep on returning the same result set from the first page.

public async getTransactionsWithPageInfo(pageFilter?: TransactionPageFilter, nextOrPreviousPath?: string): Promise<TransactionPageResponse> {
if (pageFilter) {
return await this.apiClient.issueGetRequestForTransactionPages(`/v1/transactions?${queryString.stringify(pageFilter)}`);
} else if (nextOrPreviousPath) {
const index = nextOrPreviousPath.indexOf("/v1/");
const path = nextOrPreviousPath.substring(index, nextOrPreviousPath.length);
return await this.apiClient.issueGetRequestForTransactionPages(path);
}

I'd propose either swapping the logic around such that nextOrPreviousPath takes priority over pageFilter so that consumers of the SDK can do something like

const fireblocksClient = new FireblocksSDK(...)
let transactions: TransactionResponse[] = []
let nextPage: string | undefined
do {
  const response = await fireblocksClient.getTransactionsWithPageInfo(fbFilters, nextPage)
  transactions = transactions.concat(response.transactions)
  nextPage = response.pageDetails.nextPage
} while (nextPage.length)
// `transactions` now contains all transactions

As it currently stands, the above code is also the way to reproduce this current unexpected behaviour, where transactions will just be full of duplicates from the first page of results.

Alternatively, throw an error when both pageFilter and nextOrPreviousPath are defined, to force consumer to implement the sdk is the following kind of way, which will make it clear and remove the possibility to assume behaviour

const response = await fireblocksClient.getTransactionsWithPageInfo(nextPage ? undefined : fbFilters, nextPage)
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

No branches or pull requests

1 participant