add getTransactions endpoint

[mollykarcher]

What problem does your feature solve?

Horizon will cease to serve txmeta sometime in Q2 (see discord discussion) due to data storage size concerns of Soroban transactions. The ecosystem needs an alternative to this, and we want that alternative to be the RPC.

What would you like to see?

Users need to be able to page through all transactions available in RPC's retention window. See this issue for some prior discussion/context on why we've chosen not to implement an actual stream/websocket/sse implementation here.

The getTransactions endpoint should be able to support pagination and should provide all metadata about the transaction that is currently available via getTransaction.

Scope for this will be limited to simple pagination with no filters, and we will work/propose additional filters on this as separate issues. Pagination should follow the format/user experience of the getEvents endpoint, except see (see #118) for changes that we want to make to pagination and follow the decision there.

Request format:

{
  "jsonrpc": "2.0",
  "id": <id>,
  "method": "getTransactions",
  "params": {
    "startLedger": <startLedger>,
    "endLedger": <endLedger
    "pagination": {
      "limit": <limit>,
      "cursor": <cursor>
    }
  }
}

Response format

{
  "jsonrpc": "2.0",
  "id": <id>,
  "result": {
    "transactions": [
        {
            "status": <status>,
            "applicationOrder": <order>,
            "envelopeXdr": <envelopeXdr>,
            "resultXdr": <resultXdr>,
            "resultMetaXdr": <resultMetaXdr>,
            "ledger": <ledger>,
            "createdAt": <createdAt>
        }
    ],
    "latestLedger": <latestLedger>,
    "latestLedgerCloseTime": <closeTime>,
    "oldestLedger": <oldestLedger>,
    "oldestLedgerCloseTime": <oldestCloseTime>,
    "cursor": <cursor / pagingToken>
  }
}

Tasks

Preview Give feedback

No tasks being tracked yet.

[mollykarcher]

@psheth9 @aditya1702 I added an example request/response to the description here, per our conversation yesterday. Let me know what you think

[Shaptic]

    "latestLedger": <latestLedger>,
    "latestLedgerCloseTime": <closeTime>,
    "oldestLedger": <oldestLedger>,
    "oldestLedgerCloseTime": <oldestCloseTime>,

I know this isn't hard to provide, but why do we need this?

Also, what is <ledger> in each transaction? Is is the LedgerCloseMeta, just the header, or...?

This also needs pagination information in the response, e.g. a "cursor" field for the next set of ledgers.

[mollykarcher]

I know this isn't hard to provide, but why do we need this?

I just included this because it already exists in getTransaction, but truthfully I'm not sure I know the historical reasoning so worth it to decide if we want it. If I had to guess, it's probably because it could make it easier to reason about the response from getTransaction in the case where you receive a 404. If you get a 404, it could mean 1) your transaction is "pending" and hasn't been included in a ledger yet 2) your transaction is older than this RPC instance's history and therefore you can't fetch it 3) that transaction actually doesn't exist. So oldestLedger fields could help you discern between cases 1/2.

Also, what is in each transaction? Is is the LedgerCloseMeta, just the header, or...?

The ledger sequence number. Again, mimicking existing getTransaction fields

This also needs pagination information in the response, e.g. a "cursor" field for the next set of ledgers.

+1