Transaction list issue with ICP Index canister call

Bug Report

I am facing an issue related to ICP index cannister getTransactions call. I have pushed a sample nodejs code to github repo here: GitHub - Zokshpay/icp_ledger_testing

I have followed the instructions provided in docs to have local ledger and index canister deployed with default values.

The problem I am facing is, getTransactions call always returns an empty transactions array in the response, but with the correct balance value.
But the same call done via the command line, returns the correct balance along with ‘transactions’ array with a list of transactions. Please see the attached screenshots for reference.

Any pointers on how to proceed would be great.

(min: I have tried the getTransactions call, by casting the maxResults/start args by casting in bigInt and without as well, and still get empty array.)

I am unable to put links/screenshots here, so i have added the same in readme in the github repo

You should be using the index canister ID instead of the identity canister ID here:

I’m not sure why you would even be getting a balance when connecting to the wrong canister.

Your issue is in the pagination.

const data2 = await index.getTransactions({accountIdentifier, start: BigInt(0), maxResults: BigInt(100)});

The query does not go up but down (if that analogy makes sense). If you want to query for the latest transactions, you can avoid specifying start or pass undefined.

For example:

Transaction 5
Transaction 4
Transaction 3
Transaction 2
Transaction 1

Using start as undefined or 5 and maxResults of 2 will provide transactions 5 and 4.

Using start as 3 and maxResults of 3 will provide transactions 3, 2, 1.

Can you give it a try?

1 Like

Thank you so much, that solved the problem. i had been stuck on this for a while now. My understanding was, start at block 0 and give maximum of 100 results.

1 Like

that is just wrong variable name, the value is for index canister id only. anyway, the issue is resolved, as suggested by @peterparker, it was pagination order issue.

I’m glad the issue is resolved.
The reason I thought it’s not just a variable name, is because qhbym-qaaaa-aaaaa-aaafq-cai is actually the default canister ID of the internet identity canister on a local replica.