You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
constfireblocksClient=newFireblocksSDK(...)lettransactions: TransactionResponse[]=[]letnextPage: string|undefineddo{constresponse=awaitfireblocksClient.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
getTransactionsWithPageInfo
accepts bothpageFilter
as well as anextOrPreviousPath
argument. The current logic will only usepageFilter
when it is defined, even ifnextOrPreviousPath
is also defined. This leads to unexpected behaviour where providingnextOrPreviousPath
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.fireblocks-sdk-js/src/fireblocks-sdk.ts
Lines 679 to 686 in ede50aa
I'd propose either swapping the logic around such that
nextOrPreviousPath
takes priority overpageFilter
so that consumers of the SDK can do something likeAs 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
andnextOrPreviousPath
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 behaviourThe text was updated successfully, but these errors were encountered: