SUI Graphql transactionBlocks not returning expected digests and endCursor for some addresses

[ivocryptotax]

Steps to Reproduce Issue

Go to https://sui-mainnet.mystenlabs.com/graphql

Use query:

query GetTransactionBlocks($address: SuiAddress!, $after: String) {
  transactionBlocks(first: 10, after: $after, 
  filter: { affectedAddress: $address }) {
    pageInfo {
      hasNextPage
      endCursor
    }
    nodes {
      digest
    }
  }
}

Use parameters:

{
  "after": null,
  "address": "0xd38e8c2b650693f7af0a808969a735f1868342c74fccc295ff062a03e2cde4f3"
}

Expected Result

A list of digest for this wallet with a correct endCursor for pagination.

Actual Result

{
  "data": {
    "transactionBlocks": {
      "pageInfo": {
        "hasNextPage": true,
        "endCursor": null
      },
      "nodes": []
    }
  }
}

Two things wrong here:

• this non-empty wallet with transaction history should have a list of digests, which can be seen here: https://suivision.xyz/account/0xd38e8c2b650693f7af0a808969a735f1868342c74fccc295ff062a03e2cde4f3?tab=Transaction+Blocks
• hasNextPage is true even though the node list is empty and the endCursor is null

This query works for some addresses, for example:

0xc45e5ea887e037ddc6a482afa412773b4291c8fdc338f647fb0fcea324975d8e

Doesn't work for:

0xd38e8c2b650693f7af0a808969a735f1868342c74fccc295ff062a03e2cde4f3
0x26727461b769990746a6ebea663196cd1732ff1d24e93c4fd14bc97972deed10

[wlmyng]

Thanks for reporting this issue. We've investigated and found that when we enabled pruning on the db backing graphql, there was an inconsistency in how prunable historical data was handled. This consequently affects the responses of some queries. We'll work on a fix for this issue

[pkudinov]

Hi team, is there any update on this? This is pretty critical – impossible to get transaction history for many addresses

[wlmyng]

Hi team, is there any update on this? This is pretty critical – impossible to get transaction history for many addresses

Just curious, what is your current use case? How far back in history do you require? A workaround would be to determine the earliest unpruned checkpoint available, and then use that to anchor your query. This changes only once per epoch:

query GetTransactionBlocks($address: SuiAddress!, $after: String) {
  transactionBlocks(
    first: 10
    after: $after
    filter: {affectedAddress: $address, afterCheckpoint: 93288320}
  ) {
    pageInfo {
      hasNextPage
      endCursor
    }
    nodes {
      digest
    }
  }
  availableHistory: transactionBlocks(first: 1) {
    nodes {
      effects {
        checkpoint {
          sequenceNumber
        }
      }
    }
  }
}

However, if you need more than the past 30 days worth of data, you may need to use jsonrpc instead. We're currently revamping our indexer and graphql implementations, so the current pruning configuration is a compromise for people to try things out without it being a significant cost on our end. We suggest not to scaffold any critical production applications on graphql as this is still in beta.

[ivocryptotax]

@wlmyng thank you for this suggestion.

Our use case is fetching SUI wallet transaction history for tax purposes. In our case we need the full history.

Currently there aren't any viable options for fetching all the wallet digests, rpc methods (suix_queryTransactionBlocks) don't seem to work.

Example:

The script:

rpc="REDACTED"
address="0xd38e8c2b650693f7af0a808969a735f1868342c74fccc295ff062a03e2cde4f3"
data='{
  "jsonrpc": "2.0",
  "method": "suix_queryTransactionBlocks",
  "id": 1,
  "params": [
    {
      "filter": {
        "FromOrToAddress": {
          "addr": "'$address'"
        }
      }
    },
    null,  
    100,  
    true  
  ]
}'
curl -X POST -H 'Content-type: application/json' --data-raw "$data" $rpc

Response:

{
    "jsonrpc": "2.0",
    "error": {
        "code": -32602,
        "message": "Error checking transaction input objects: Unsupported(\"Some(FromOrToAddress { addr: 0xd38e8c2b650693f7af0a808969a735f1868342c74fccc295ff062a03e2cde4f3 })\")"
    },
    "id": 1
}

[pkudinov]

@wlmyng is there any update here? What is the best way to fetch transaction history for a wallet? RPC solution doesn't work, so maybe there is an option whereby GraphQL could still return all transaction hashes, and then we can use RPC to fetch transaction blocks themselves?

[wlmyng]

You should be able to use graphql without the workaround now, we've cleared out the dead tuples that were bloating the db. However, note that these public good rpcs will remain pruned to the last 30 days. Our recommendation is for your team to spin up a custom indexer so you have greater control over data retention needs.